Is there a built-in way to destroy a session cookie generated by Dancer::Session::Cookie after a certain amount of minutes of it being idle? I noticed that it doesn't even destroy the session when I restart either the Nginx or Starman server, which is not what I want (for security reasons).
If there is no built in way is there anything inherently wrong with storing the last time the session was active in an SQL database and updating it after every action? Then if more than 15 minutes or so have gone by without that entry being updated the session cookie will be destroyed (with session->destroy). That doesn't seem like the best solution but maybe that's the only way. From my understanding you can also manually set a cookie expiration time in the HTTP header but that would only destroy the cookie on the client-side, correct?
I think you want to do the reverse.
When you generate the cookie, use the expires attribute to set it to, say, "15 minutes":
https://metacpan.org/pod/Dancer::Cookie#expires
Then every time you do something for that session, call the Dancer::Cookie init method:
https://metacpan.org/pod/Dancer::Cookie#init
... to refresh the cookie (if you're not using the default path, pass in the path).
The user's browser should expire the cookie for you after the given time.
(I have not actually tried this, but the code implies it should work - the documentation for the init method could certainly be clearer)
Related
I am creating a website using Parse, and I have run into an issue. When I let my browser sit around for a couple hours, calls to the graph API don't seem to work anymore. The response from the graph api is:
Error validating access token: Session has expired on Wednesday,
29-Apr-15 00:00:00 PDT. The current time is Wednesday, 29-Apr-15
21:34:32 PDT.
Of course, my token has expired... but now I can't find a way to easily refresh my access token without sending the user back through the login process... which isn't an ideal workflow.
A glimmer of hope in the Facebook Javascript documentation has me wondering if I am potentially just doing something wrong. If not, their documentation is horribly misleading.
Also keep in mind that the access tokens that are generated in
browsers generally have a lifetime of only a couple of hours and are
automatically refreshed by the JavaScript SDK. If you are making calls
from a server, you will need to generate a long lived token, which is
covered at length in our access token documentation.
source: https://developers.facebook.com/docs/facebook-login/login-flow-for-web/v2.3#token
What can we do to automatically refresh this token?
The JS SDK should automatically provide fresh access tokens, yes – although I am not sure if it does so if you just have the app open for a couple of hours without interacting with it (meaning: reloading the page, so that the JS SDK gets re-initialized as well). Since this is not a very common use case, it might not.
I would suggest that you try and use FB.getLoginStatus to get a fresh access token. (There should be no need to then set this access token explicitly on subsequent API calls; that the SDK will handle itself.)
This method uses an internally cached result, to avoid having to make a request to Facebook every time it is called. Since the expiry time of a token is known, I would expect the SDK to be able to decide itself if an actual request is necessary again – but if it doesn’t, you can also force a new request by setting the second parameter to true. (This is however not recommendable for every call, so I would try and see if calling the method without it is able to resolve the problem already.)
A simple workaround is to make an API call before the current access_token expired.
Let's say the token expires every 2 hours, you can, for example, make a simple /me call every 1H30 :
/**
* Make an API Call to refresh the access_token
*/
function tokenRefresh() {
FB.api("/me", function (response) {
// the token is refreshed
});
}
// call it every 1H30
var tokenTimeout = window.setTimeout(tokenRefresh, 5400000);
If you don't want that code be executed when your user uses the app, so when it will be useless, you can, each time you make a request, reset the timeout in the callback :
window.clearTimeout(tokenTimeout);
var tokenTimeout = window.setTimeout(tokenRefresh, 5400000);
Therefore, your app makes a call each 1H30 that passed without an API call.
I have written a pretty straightforward REST service in Domino 9.0.1. I have a view with about 160K records, each record has about 10 field, and the first field is the key.
From time to time I need to make a change to the service, and when I remake the web service call (from the url in my web browser for instance), the data doesn't necessarily change. It seems it is cached on the there server. I believe it is a server issue as I still get the same results even if I switch to another browser. Sometimes I will change my parm and I get DATA FOR THE PREVIOUS PARM I ENTERED. This is terrible.
How can I reset the web service or flush the cache?
You have few options:
1) Add unique parameter to REST url, e.g.: http://hostname/rest/api/endpoint?systemtime=...
Where you compute systemtime value using System.currentTimeMillis()
2) Use HTTP request cache control headers, see http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Avoiding_caching
I just discovered that when I configure the session plugin of a Catalyst app (Catalyst::Plugin::Session) to expire, it screws with the flash data. More specifically, I'm finding that flash data no longer carries over with a new request.
Does this sound normal? How might I cope with this?
Perfectly normal. The whole point of sessions is to be able to associated data from one request with data in another request. When you let the session for some request expire, you are saying that that request's data shouldn't have anything to do with any future request.
More specifically, the flash data is a part of the session data -- see the _save_flash method in the Catalyst/Plugin/Session.pm file, for instance. Also see the big warning for the delete_session method:
NOTE: This method will also delete your flash data.
How to cope with it? You need to persist data from a request using any scheme other than the Session plugin. Without knowing more about your app, what data you are trying to persist, and how you will associate data from an old session with a new request, I couldn't begin to make a more specific recommendation than that.
When configuring the session for example with a database backend you'll have to add flash_to_stash as an option:
<session>
dbi_dbh DB
dbi_table sessions
dbi_id_field id
dbi_data_field session_data
dbi_expires_field expires
flash_to_stash 1
expires 3600
</session>
Based on this question I asked earlier on setting up cookies in Perl, I successfully got an answer and way to do this but am now faced with a new interesting challenge.
In Perl CGI scripts, it demands you setup a cookie on the header statement which ought to be the first statement in your script. To clarify, you need to have a CGI->header() statement at the top of your script for the CGI script to work!
My scenario:
I have a login screen with a user name and password, upon successful login I need to setup a cookie with the current user name, then redirect the user to another form that checks if the cookie is set before allowing any transactions.
Please note if I set the cookie after the CGI->header() statement, it never get set, and if I set it at the top of my script, it has a bogus value for obvious reasons (user has not logged in)
How do I achieve this? does the CGI->header() statement need to be at the top of my script always?
Gath
Your assertion is wrong: print CGI->header can appear anywhere in your script. However, headers must be output once and only once and before any other output is emitted.
For your purposes, I would recommend using CGI::Application along with CGI::Session (via CGI::Application::Plugin::Session).
You're gonna end up writing yourself some code that can be hijacked if you keep heading in that direction, given your current level of knowledge ("just enough to be dangerous").
I'd suggest reading my article on how to "brand" a browser using cookies. It's an oldie-but-a-goodie.
For the impatient, the trick is to use a cookie only to distinguish one browser from another, and keep everything important as server-side state.
I'm writing a Catalyst application that's required to have a fairly short session expiration (15 minutes). I'm using the standard Catalyst framework authentication modules, so the user data is stored in the session -- i.e., when your session expires, you get logged out.
Many of the uses of this application will require >15 minutes to complete, so users will frequently submit a form only to find their session state is gone and they're required to log back in.
If this happens I want to preserve the original form submission, and if they log in successfully, continue on and carry out the form submission just as if the session had not expired.
I've got the authentication stuff being handled by an auto() method in the controller -- if you request an action that requires authentication and you're not currently logged in, you get redirected to the login() method, which displays the login form and then processes it once it's submitted. It seems like it should be possible to store the request and any form parameters when the auto method redirects to the login(), and then pull them back out if the login() succeeds -- but I'm not entirely sure of the best way to grab or store this information in a generic/standard/reusable way. (I'm figuring on storing it in the session and then deleting it once it's pulled back out; if that seems like a bad idea, that's something else to address.)
Is there a standard "best practices" or cookbook way to do this?
(One wrinkle: these forms are being submitted via POST.)
I can't help thinking that there's a fundamental flaw in mandating a 15 minute timeout in an app that routinely requires >15 minutes between actions.
Be that as it may, I would look at over-riding the Catalyst::Plugin::Session->delete_session method so that any contents of $c->request->body_parameters are serialised and saved (presumably to the database) for later recovery. You would probably want some rudimentary check of the POST arguments to ensure they're what you're expecting.
Similarly, create_session needs to take responsibility for pulling this data back out of the database and making it available to the original form action.
It does seem like a messy situation, and I'm inclined to repeat my first sentence...
UPDATE:
Whether you use delete_session or auto, the paradoxical issue remains: you can't store this info in the session because the time-out event will destroy the session. You've got to store it somewhere more permanent so it survives the session re-initialization. Catalyst::Plugin::Session itself is using Storable, and you should be able to with something along these lines:
use Storable;
...
sub auto {
...
unless (...) { #ie don't do this if processing the login action
my $formitems = freeze $c->request->body_parameters;
my $freezer = $rs->update_or_create(
{user => $c->user, formitems => $formitems} );
# Don't quote me on the exact syntax, I don't use DBIx::Class
}
...
my $formitems = $c->request->body_parameters
|| thaw $rs->find({$user => $c->user})->formitems
|| {} ;
# use formitems instead of $c->request->body_parameters from here on in
The underlying table probably has (user CHAR(x), formitems TEXT) or similar. Perhaps a timestamp so that nothing too stale gets recovered. You might also want to store the action you were processing, to be sure the retrieved form items belong to the right form. You know the issues for your app better than me.
I would store the form data as some sort of per user data in the model.
Catalyst::Plugin::Session::PerUser is one way of doing that (albeit somewhat hackishly). I would reccomend using the session plugin only for authentication and storing all the state info in the model that stores your user data instead.
And I totally agree with RET's opinion that the 15 minute limit seems really counter productive in this context.
I came across this whilst searching CPAN for something entirely unrelated.
Catalyst::Plugin::Wizard purports to do exactly what you need. The documentation suggests it can redirect to a login page whilst retaining the state of the previous action.
NB: I haven't used it, so can't vouch for its effectiveness.
In the end, we ended up grabbing the pending request (URL+params) in the auto(), serializing and encrypting it, and passing it via a hidden form element on the login page. If we got a login request with the hidden element populated, we decrypted and deserialized it and then redirected appropriately (making sure to pass through the standard "can this user do this thing" code paths).
You could always have some javascript on the client that keeps the session from expiring by making a small request every few minutes.
Or you could have AJAX check for an active session before posting the form and presenting the user with a new login box at that time if needed.