I have a problem with the session way of working. I´ve made an CMS application integrated with database for the purpose of making a web site easier to change and update.
###################
THE FACTS:
###################
Lets review the process to see the real problem.
1- Browser. Site URL. Access to a public site.
2- Session starts with global variables. Needed for making all the tools (more than 7) work for the right company without having to pass the variables from one page to the next one (to many pages, libraries, functions, etc), and then on
-. Group name (anonimous). Each group has its own menu of web pages non dependent of any other, that means that each group is a site public (URL) or private (log in)
-. User name (anonimous)
-. Site name (URL).
-. Company name (URL owner)
3- The user has a login in (User and password) so the session must change variables.
-. Group name (the one of the user)
-. User name (user)
-. Private site. So the system shows the tool bar of the system.
Untill then, there´s no problem in the system, but here´s where the problem starts.
PROBLEM (A)- The user opens a new browser in order to see the changes he has made to the contents. He navigates through the public site to look. When he does so as the system previously did recognize the URL in the first place will do again. Then all the variables will be reset to anonimous user and group. When the user comes back to the first browser to continue making changes finds one of the following:
-. the system doesn´t permit him to continue and he has to log in again. (thats not comfortable)
-. the system permit some of the changes as anonimous user so he will never find again the changes he made. (thats wrong)
PROBLEM (B)- The user opens a new browser with the URL of another company, concidentily that site is hosted in the system too, so the system makes the same as in PROBLEM (A) plus the user goes to he´s tools in the other company and starts making changes:
-. the system doesn´t permit the access. (thats good but uncomfortable)
-. the system permits changes because concidentily recognizes the group name. The user begin to see the wrong menu. (that´s the worst of all, the user could make changes to sites that he doesn´t own)
PROBLEM (C)- The user opens many browsers of many companies hosted in the system. So the problems start to multiply. (very bad)
PROBLEM (D)- The user access another site thas also made in PHP with sessions. Some of the variables maybe reseted by the other site or the way around. (disconcerting).
###################
THE PROBLEM:
###################
PHP session start only once in the user machine. I haven´t found a way around.
1- With the first browser that initiates it.
2- You can open an close browser windows and as long there´s one browser open the session remains the same.
3- Many diferent applications can mix variables without knowing.
4- You need different applications to work together without making a mess complicating the integration process.
###################
SUGGESTED SOLUTION:
###################
The problems could be solve
1- if the PHP session could be started with unique PIN number on request.
2- if the session could be different from browser to browser.
3- if you could have different instances of the session.
4- if you could have different instances of the variables.
5- if you could start the variables with a unique vector variable or some thing like that.
Well, as with any other, I need feedback on the problem in order to know what to do (if I haven´t discover the right PHP functions to do the job), or this is something the the comunity is working on.
Thanks in advance,
Zaaptar Chazzy
PHP Developer
zaaptar@yahoo.com
MULTIPLE PHP SESSIONS ON THE SAME CLIENT PC
Moderator: General Moderators
- mydimension
- Moderator
- Posts: 531
- Joined: Tue Apr 23, 2002 6:00 pm
- Location: Lowell, MA USA
- Contact:
take a look at the setcookie manual and the cookies specs.
e.g. http://wp.netscape.com/newsref/std/cook ... html[quote]
domain=DOMAIN_NAME
When searching the cookie list for valid cookies, a comparison of the domain attributes of the cookie is made with the Internet domain name of the host from which the URL will be fetched. If there is a tail match, then the cookie will go through path matching to see if it should be sent. "Tail matching" means that domain attribute is matched against the tail of the fully qualified domain name of the host. A domain attribute of "acme.com" would match host names "anvil.acme.com" as well as "shipping.crate.acme.com".
Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us". Any domain that fails within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".
The default value of domain is the host name of the server which generated the cookie response.
path=PATH
The path attribute is used to specify the subset of URLs in a domain for which the cookie is valid. If a cookie has already passed domain matching, then the pathname component of the URL is compared with the path attribute, and if there is a match, the cookie is considered valid and is sent along with the URL request. The path "/foo" would match "/foobar" and "/foo/bar.html". The path "/" is the most general path.
If the path is not specified, it as assumed to be the same path as the document being described by the header which contains the cookie.[/quote]this might help to avoid intraserver/interapplication problems
e.g. http://wp.netscape.com/newsref/std/cook ... html[quote]
domain=DOMAIN_NAME
When searching the cookie list for valid cookies, a comparison of the domain attributes of the cookie is made with the Internet domain name of the host from which the URL will be fetched. If there is a tail match, then the cookie will go through path matching to see if it should be sent. "Tail matching" means that domain attribute is matched against the tail of the fully qualified domain name of the host. A domain attribute of "acme.com" would match host names "anvil.acme.com" as well as "shipping.crate.acme.com".
Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us". Any domain that fails within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".
The default value of domain is the host name of the server which generated the cookie response.
path=PATH
The path attribute is used to specify the subset of URLs in a domain for which the cookie is valid. If a cookie has already passed domain matching, then the pathname component of the URL is compared with the path attribute, and if there is a match, the cookie is considered valid and is sent along with the URL request. The path "/foo" would match "/foobar" and "/foo/bar.html". The path "/" is the most general path.
If the path is not specified, it as assumed to be the same path as the document being described by the header which contains the cookie.[/quote]this might help to avoid intraserver/interapplication problems
How are you opening the new browser window? I have experienced similar problems when you open the new browser window within the existing browser (file -> new or shift+click on a link). If you use the Internet Explorer icon on the desktop (or quick launch bar) it should get a new session ID.
I think the session ID with PHP is determined when the browser first connects with the server. If you spawn a new window it keeps the session ID.
I think the session ID with PHP is determined when the browser first connects with the server. If you spawn a new window it keeps the session ID.