Hello, I have a question. I have a site (for a client) under 1 domain. A user can log in via different login forms. This leads to differences in their session and rights, but not in the resulting domain. The problem is the following:
- User A logs in using form 1
- User A is now in the application in tab 1
- User A logs in using form 2 using a second tab in the same browser
- User A is now also in the application in tab 2
- User A logs out in tab 1
- User A is now automatically logged out in tab 2 as well!
We do not want the last thing to happen. In fact it is even worse, because when user A logs into tab 2, the rights that are set there overwrite his rights in tab 1. So basically: he has one session that is influenced by two different logins.
I do not know how to deal with this exactly. I’m hoping I can have a session per tab, but am not sure if this is possible. Hope to hear your thoughts.
I would first question why there are so many disparate ‘applications’ within which a user can log into, and look to unify the login, access control and session management for all of them.
That said, however, one solution would be to roll your own session management and use cookies and session structs with different names for each application. For instance:
- Application A uses
sessionA as the cookie name and session.sessionAObj as the session struct
- Application B uses
sessionB as the cookie name and session.sessionBObj as the session struct
More information on how to accomplish this can be gleaned from the code security section on cfdocs.org. In particular, the article on Session Management should help get you going in the right direction.
HTH
– Denny
I no longer use sessions.
Instead, I pass a guid in the url of every request and login the user each time they navigate to a new page.
That sounds woefully insecure. Where does the GUID come from and how is it stored? Does it change with each request or is it the same for that user always?
If you’re going to do that, just disable session cookies and use addToken on all your cflocations and add the cfid and token to all URLs. CF has supported cookie-less session forever. And yes, it does have security issues. The biggest of which is how much easier session hijacking can be made since sharing URLs between users shares sessions.
That’s putting it mildly IMHO.
Or, how much easier it is to purposefully hijack another users session, for that matter. This is a well known and easily exploited vulnerability.
Cookie-less sessions fell out of favor in what, v6.1, v7? I could not, in good faith, advocate that anyone should ever actually do this.
It’s their login id. It stays the same for that user until the end of the semester.
My users never timeout now.
It’s not the same as ColdFusions tokens. The guid comes from sql server.
The same security issues that apply to CF tokens applies to your situation. Any user (or any hacker) could use any other users GUID value to hijack that users session. And since user sessions never timeout, they are susceptible to hijack 24/7.
In addition, by giving the GUID that is stored in SQL on the URL, you’re exposing information that could lead to information disclosure if your database is ever breached (either directly or indirectly via SQL injection). And, if breached, a hacker could readily use any users GUID to hijack any users session at will.
Denard is correct Phillip. It is HIGHLY insecure and actually surprises me
that people still do this when not transferring between separate servers.If
you value security at all, stop doing this.
If you just don’t want users to time out (which I don’t see as an issue),
set their timeout to some very high number in the admin panel.