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>
Related
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)
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
Can someone explain the difference between this two frontends
Zend_Cache_Frontend_Capture and Zend_Cache_Frontend_Page?
the Capture is the default one for page caching ... the weird thing is, it makes the id with get variables, but there is no options to set make_id_with_get_variables like its the case in
Page frontend....
can someone explain this ?
Here is my effort to explain the differences between the two.
To start out, let's look at Zend_Cache_Frontend_Capture. The reference states that this class is designed to work only with Zend_Cache_Backend_Static.
You would use Zend_Cache_Frontend_Capture to cache entire pages that have no relation to the user accessing the site. You use this frontend when you have static data (that could change from time to time) that has no relation to the current user, that is, it is the same for all users (like an RSS feed or dynamically created JavaScript file for example.
Looking further into the Zend_Cache_Backend_Static, you will see that this backend is a bit special. It requires rules in your .htaccess file to assist with serving the cache. Once you have cached something with Frontend_Capture/Backend_Static, PHP and Zend Framework are NOT used in order to serve the cached data. Apache sees that the cache file exists based on your .htaccess and serves the content directly to the user without invoking PHP.
Zend_Cache_Frontend_Page on the otherhand works differently. With it, you can cache content not only based on the request URI, but also based on information in a cookie, session, GET, or POST parameters. By default, caching based on cookie, session, get, and post is disabled, so for this to have any effect on a user logged into your site, you have to tell the cache if there are any pages you want to cache based on that information.
Once I create a cache and tell it I want to cache based on cookie and session, I can now cache a dynamically generated page that is specific to one user. So if person A accesses /accounts/, the page can be cached for that specific user containing the list of their accounts that was pulled from the database. Now when person B accesses /accounts/, they do not see the cache for person A, so the page is now cached separately for them with each respective user's information in their own cache.
In summation:
Use the Capture frontend when you have data you can cache that is the same for ALL users. This will be a higher performance cache since PHP and ZF is not needed once the page is cached. The downside is having to add caching rules to .htaccess
Use the Page frontend if you want to cache pages with dynamic output based not only on request URI, but the cookies, session data, or get/post parameters.
Hope that is clear and helps you understand the differences.
EDIT:
I believe I see what the problem is, not sure if this is classified as a bug or not though.
Zend_Controller_Action_Helper_Cache::preDispatch() generates the cache ID based on the request URI (which includes the query string). Since the jQuery ticker appends a query string to the URL, you are caching one copy of the feed for each request URI. (Look for $reqUri in the aforementioned class method).
I see a couple of options: 1) See if you can get the ticker to not append the query string (at least for that specific URL) or 2) Manually start the Capture cache and pass your own ID, rather than letting the cache helper generated it based on the request URI.
I want to post some data to the server, and in response, I want to create a CSV file, with application/excel as the MIME Type (recently recognized as Internet Media Type), to force the browser to open the generated CSV file in Microsoft Excel. However, I also want to prevent user from re-submitting the same info (re-posting the form) by any accident as the result of refreshing the page.
With simple CRUD operations, I use Post/Redirect/Get pattern, so that any further refreshing will only send HTTP Get Request to the server, without any parameter, thus not changing server's state (Idempotence).
What is the recognized pattern for stopping user from re-submitting (re-posting) the same info to the server, when the response is not a page, but a file?
Any idea?
The Post/Redirect/Get pattern is an answer to a browsing event.
Here, there is no browsing action (the form submission only open a 3rd party app, i.e excel), and so any kind of browsing related pattern will be useless.
I suggest you use both a server side trace of the initial submission (with a unique token maybe), so you can prevent the file generation, and an easy to write client side script like <form onsubmit="this.onsubmit = function(){ return false ; }">
I can offer you one other solution.
Take hash (MD5/SHA256 ..) of your submitted data. The hash will be [fairly] unique.
Put it in list in a session with a time limit, say 5 minutes.
Even your user submit same data. Hash will be same and you can give error message to your user.
If different users can post same data, you can also hold user information in the list. And give error message according to user.
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.