Session expiration

It saddens me that i can not allow a user session to NEVER expire until log out… So i looked into just on log in setting my user’s session expiration time to say a year in the future. But that doesn’t seem to be possible either. is there a way to on log in override the ticket expiration? or maybe in roles asign a default of 1year to a given user type?

Hey Erik, session override will be in version 1.6 shipping next week. I will post instructions once I talk to Lee, who implemented the code.


1 Like


After running this by engineering, Lee was able to provide some valuable insight that is a temporary fix for the session expiration issue. Know that this is no “fix” for this in release 1.6, but a real fix will come in 2.0 when we re-write session handling.

But you can get it to work using the default session and the “duration” url parameter on login. Here is what you have to do (which I assume will not be ideal for clients because it deals with cookies).

This currently works by setting a "duration" field greater than 0 (default) in the login request as below (the launchpad checkbox currently sets the duration = 3600 * 24 * 30 i.e. 30 days).

curl -i -k -3 -X POST http://localhost/rest/user/session \

-H “X-DreamFactory-Application-Name: todojquery”
 -d ‘{ “email” : "", “password” : “Password123”, “duration”: 3600 }’

The -i option above dumps response headers. You will see that the server is setting the session cookie as well as an additional hashed cookie that can be used to “re-create” the session later after it “expires”. Notice the “expires” value.

Set-Cookie:PHPSESSID=ediaffcjdlukhi9jflpntl7ch3; path=/; expires=Wed, 11-Jun-2014 13:03:06 GMT; path=/

While we recommend using the X-DreamFactory-Session-Token in following calls after the login, which works until the aforementioned garbage collection runs, it will not work indefinitely due to the current header processing. So calls like this…

curl -i -k -3 -X GET http://localhost/rest/db/todo 
 -H “X-DreamFactory-Application-Name: todojquery”
 -H “X-DreamFactory-Session-Token: o4h6bfel1hmslti69e2880ia17”

Will eventually give you the “No valid session” error. What does work is to send the cookies (both of them) generated from the above login, but not the X-DreamFactory-Session-Token which overrides this behavior.

curl -i -k -3 -X GET http://localhost/rest/db/todo 
 -b “PHPSESSION=onp2sanr1o4sjc41p66b1sgmv6; 279d658aeca916be9eda1385aac; expires=Wed, 11-Jun-2014 18:09:05 GMT; path=/” \ -H “X-DreamFactory-Application-Name: todojquery”

This causes the session to be regenerated (though it doesn’t seem to have everything stored in it as we do on login) and processes the call as normal.

Logout kills the duration cookie and the session expires and is garbage collected…

curl -i -k -3 -X DELETE http://localhost/rest/user/session \

-H “X-DreamFactory-Application-Name: todojquery”
 -H “X-DreamFactory-Session-Token: o4h6bfel1hmslti69e2880ia17”

Date:Wed, 11 Jun 2014 12:23:20 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMTKeep-Alive:timeout=5, max=100Set-Cookie:279d658aeca916be9eda1385aac9b2fd=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/

Hopefully, this clears thing up for you until there is a permanent fix for this issue which will be in a future release (2.0) - Have a good one, Erik!

  • Mark
1 Like

I’m running 1.7, but I can’t find this option anywhere. Can you help me out here? Thanks.

If you write an app that runs in the browser it can POST to /rest/user/session to log in to the DSP. You include a duration > 0 to enable the session timeout option. Is that what you are asking?

POST { “email” : "", “password” : “mypassword”, “duration”: 3600 }