I need to maintain a variable in persistent scope, that is until user session is active. Problem is application does not allow session management and it is not possible to change that.
I want to display a message to the user only once in logged in session. What are my options except session and if possible except using DB.
This is a very long comment. It won't answer the question but it might give the questioner some ideas.
I wrote and still maintain a ColdFusion application that has sesssion management set to false. This app displays html content inside a desktop application - not a web browser. Security is handled by the desktop application. If you can log into that application and are the appropriate type of user, you can access the html content.
On the ColdFusion side, the possibility of someone discovering the url and trying to access the site with a web browser must be handled. That's done with data. The desktop application puts a UUID into a database and sends it as a url variable. ColdFusion checks to see if the UUID exists and is sufficiently recent. If that check fails, the user is sent to a "shame on you for trying" page. This is done in the onRequestStart method of Application.cfc
Other relevent variables are sent to ColdFusion from the same database record as the UUID, but they could conceivably also be url variables. The onRequestStart method copies these variables to the request scope which is used in the other ColdFusion pages.
you can set a session cookie using cfcookie that doesn't use the expires attribute. This would cause the cookie to expire when the user closes the browser. Your cookie would indicate whether or not the message has been displayed.
<cfif structkeyexists(cookie, "message_displayed") eq false>
<cfcookie name="message_displayed" value="true"/>
<p>Your Message Here</p>
</cfif>
Related
How can I close sessions in Django if a user moves from my site to another or if he close the browser.
From both the question and comments, seems you would like to "close" session when user exits your site without any aid from JS. The answer is it depends how you define "close".
Root of the problem is that HTTP is stateless. Each request coming into the server is completely independent request without any relation to any other requests which means there cannot be any state. Since state is very useful we hack HTTP to add state by using sessions. The idea is that browser sends some identifier to some state stored on the server which allows the server to retrieve that state hence give some context to the request. The key there is that the browser is sending that data. In other words, if the browser at some point will stop sending requests, (e.g. user closes the tab), the server will never know that. Therefore if you define "close" session as removing session from the server, no that cannot be possible without some JS help.
If however all you are trying to achieve is log the user out when they exit your site, that can partially be done in Django with the use of SESSION_EXPIRE_AT_BROWSER_CLOSE setting. Here are additional docs about that. The idea here is that when Django sends the session cookie back to the browser, it will indicate to it that the session cookie should expire when the browser is closed. In that case when the browser is closed, the browser itself will invalidate the session hence the user will be forced to create new session on next visit. This is partial solution since the session will still be stored on the server and I believe only works when browser is completely closed (I dont think closing tabs works but not certain). To mitigate the issue of the server accumulating old sessions, Django provides a management command clearsessions which you should run on regular basis.
I have a problem with session variables in my app. To make it short, my coldfusion application is inside a dot net application using iFrame. The Main application is using dot net so user login to dot net app.
Once user successfully login they can access my coldfusion app. through a link. So there is no login to my coldfusion app. (Boss does not want our users to login twice!).
To differentiate each user, the dot net app pass two url variables, url.userid and urlusergroup to my coldfusion app. Then I created session variables based on these url variables, such as session.userid and session.usergroup, to differentiate each user and their roles when they are roaming in my coldfusion app.
This is how I create the sessions:
in my application.cfc (ColdFusion 10) OnSessionStart I have:
<cfset session.userid= url.userid>
<cfset session.usergroup= url.usergroup>
If I login as user A, those two sessions are created then when I log out (through the dot net app), then login again as user B, another set of sessions are created for user B but the session variables that belong to user A still exist. This mess up everything.
To only maintain 1 set of sessions running at a time, I do the following in my index.cfm:
<CFIF StructKeyExists(session,"userid") >
<cfif session.usergroup NEQ URL.usergroup AND session.userid NEQ url.userid>
<cfset sessionInvalidate() />
<cfset session.userid = url.userid>
<cfset session.usergroup = url.usergroup>
</cfif>
</CFIF
This work, I can login and log out as different users with different roles and access perfectly but one thing that I notice still stay the same is the cookie.
When I cfdump var="#cookie#" I see the same jsessionid=C2AEE274A09334EB98CCB2D332D6CADA.cfusion
My question is: should I do something with the cookie? should I also make it expired and rebuilt the cookie for every new user just like what I did with their sessions?
How to delete a cookie and how to rebuild one for the user?
Not quite the answer you are looking for, but it does seems to me that you could have a bigger problem though - are any of the URL params numeric or 'plain text'? If so any user can see the URL params being passed via the iframe, so could easily change the userid and/or the usergroup which presumably would give them access to things they shouldn't.
For example if the iframe calls:
http://mycfapp.com/?userid=123&usergroup=2
Then by tampering with the params I could potentially login as a different user:
http://mycfapp.com/?userid=1&usergroup=2
You need to think about securing these. You could get the .net application to call CF server-side to authenticate and get a token which you can then pass in the iframe. That way you can provide a time-sensitive token without the user ever seeing the ids being passed as simple URL params.
You could also have your .net application call CF when the user logs out to invalidate the token.
Expanding on what John said, you need to make two calls from your .net application.
First will be for authenticating the call from .net system. In response to that you should give back a token. You can save this token into your session or database against the userId.
Then using that token, you should allow .net application user to be able to access your ColdFusion application. You can set a timeout on that token based on user journey.
I'm using session to store an object id and its description, this instance should be blocked to all other users while it is beign used in someone's session, and I would like to release the user object once he closes the browser, now I'm aware there is a configuration to expire sessions on browser close, I was just wandering if there is any entry point where I could add some custom code
What I'm trying to achieve is something like
def OnSessionExpire(???):
#release my objects
I've searched around but found no answer, can someone lay a help here? I'm using the backend session mode
Thank you !
Django doesn't do anything at all when the browser closes. Django doesn't even know - how can it: the only time Django knows anything about what you do in the browser is when you make a request to the server, but closing the browser is the opposite of making a request.
Session expiry on browser close is an attribute of the session cookie, not anything that Django does. It just means that the cookie is set with a flag that tells the browser not to persist it when it closes. The actual session data remains in Django's session store, and will do until you explicitly clear it, but is not accessible because the cookie has been removed.
So, the upshot of that is that there is no way to tell explicitly when a session ends. The only thing you can do is to send regular keepalive signals - eg via Ajax - while the session is open, and taken an action if you haven't seen any for a while.
I've inherited a ColdFusion site, despite no background in CF, but have been tasked with making a change to the behavior of the site. I'm running into a problem with cookies, though.
A site on another domain is linking to this site and includes a query string. Now I'm checking for that value (a zip code) in the index.cfm file and storing it in the cookie and that seems to be working fine. I looped through the cookie collection and dumped the results, and the zip code was there. So at this point, all is well.
But then the user clicks on a button, which reloads the index.cfm file with a different <include>, and the cookie no longer has any values other than CFID and CFTOKEN. This was confirmed by looping through the cookie collection, and later by Fiddler.
Client storage is set to cookie, and I can't find anywhere in the index.cfm, application.cfm, or the included files where the cookie is being set to expire.
Here's the line that's storing the value:
<cfcookie name="ZC_Zip" value="#ZC.ZC_Zip#" expires="NEVER">
What else should I be looking for to figure this out? It's ColdFusion 5, if that helps.
Cookies without a set expiration are set to a default of expiring at session close. Could this reload be resetting the session of the user?
How long can I use a session cookie? I have a client application where I authenticated to a SharePoint site and I am using the cookies for navigating through the subsites. I am saving the cookie and reusing the headers to login to the site at a later point without authenticating again. There is no expiration date set. How long will the cookie last and when should I authenticate back again?
The expiration of session cookies varies from browser to browser. I was unable to find any kind of reference giving the current specifics per browser. It used to be that session cookies would be destroyed when the browser was closed, but some browsers now have settings that, if enabled, will cause session cookies to persist past the browser being closed. For example, Firefox's "When Firefox starts: Show my windows and tabs from last time" will cause this to happen, somewhat surprisingly. The same goes for, "On startup: Continue where I left off" in Chrome.
I don't really care for SharePoint so I haven't used it in a while, but as I recall it uses ASP.Net Forms Authentication, pulling the configuration from the web.config just like any other ASP.Net site. That being said, you're not really concerned with the timeout of your cookie. What you care about is the timeout of your server-side session token - that is to say, how long the data contained in said cookie will be recognized by the server. That is set by the timeout property in the forms tag of the web.config file for an ASP.Net app:
<system.web>
<!-- ... -->
<authentication mode="Forms">
<forms timeout="2880" />
</authentication>
<!-- ... -->
</system.web>
If there's no expire it's going to be around until the browser is killed. Normally in ASP.Net the session cookies are set with a 20 minute timeout. That's usually pretty good. Depending on your app, you may want a javascript timer as well. Otherwise the browser won't understand when it's logged out until a page refresh happens and sensitive data can be exposed. You'll see this implementation on any online banking site.
(Edit to clarify from downvote)
Session cookies do, in fact, stay around until the browser is closed. You can look it up here: http://www.allaboutcookies.org/cookies/cookies-the-same.html
The above answer is also correct in that some newer browsers will recover session cookies after a crash/close.
#Grinn, you do bring up a good point able the Ticket. When using ASP.Net Forms auth, an encrypted Ticket is placed within the session cookie. They cookie can still be in place as far as the browser is concerned, but if the datestamp inside the ticket is expired, it will be considered invalid.
If you're using some semblance of Forms auth with Sharepoint, you should probably just write your own membership provider that can crack the Ticket in the cookie, but disregard if the datestamp is expired. Building Custom Membership Provider