I use Zend_Session::rememberMe(60*60*24*90); to make the session of a logged-in user to last for 90 days.
I've read the Zend_Session documentation but didn't find any method to check that this expiration is actually set somewhere.
I cannot check the browser cookie, at least directly, as the webpage is embedded within an Adobe Air widget.
If you just want it for debugging purpose use:
var_dump($_SESSION['__ZF']);
you can see all of the values stored in zend session including rememberme 's expiration.
Related
I am trying to set the AppClip invocation for my App which is already released on app store.
I need an url such that it provides me a jobId e.g.: https://example.com/task?jobId=00001.
My use case is that I send the sms with the url https://example.com/task?jobId=00001 to the user, the user clicks on the url and the app gets started. Then for the other user I send the next url with corresponding jobId.
I did setup the AASA file for my domain (contains the JSON with "applinks" and "appclip" objects) which is valid, also the Domain status is valid on App Store Connect. There is a default experience set with title, subtitle, image and action. I also configured an advance experience for the url https://example.com/task.
However, my app clip doesn't get invoked if I access the url from either sms text or safari. :(
I do not have a web page for https://example.com/task therefore I haven't set up the meta data for this.
Is it possible to invoke the AppClip this way? It is really important for me that the URL is dynamic and I pass that jobId every time for each individual booking.
There s no much documentation and I already read at least twice Apple documentation about AppClip.
Because of this:
I do not have a web page for https://example.com/task therefore I haven't set up the meta data for this.
The answer to this:
Is it possible to invoke the AppClip this way?
Is no. Sorry, you need to own the domain you're working with, or at the very least have means to access its CNAME config (thus, be able to induce the owner of that domain to change the CNAME configs to what you want it to be, similar to what branch.io and AppsFlyer does with its users/clients).
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 am using the PHP SDK getLoginUrl() function which works perfectly to log the user in. Once the user is redirected back to my page, the URL can come in two forms, see in the following link subsection 3: http://developers.facebook.com/docs/authentication/server-side/
Part of the return URL is a ?state= value. This value is supposed to be used to prevent Cross Site Request Forgery: http://developers.facebook.com/docs/reference/dialogs/oauth/
Though, using the getLoginUrl() method I can never set a state value as it is not one of the parameters: http://developers.facebook.com/docs/reference/php/facebook-getLoginUrl/
So how can I utilize the state-value to log a user into facebook and prevent CSRF?
So how can I utilize the state-value to log a user into facebook and prevent CSRF?
This is being automatically handled by the Facebook PHP SDK. If you were about to write your own API calls to Facebook, you would need to submit the state manually (if desired) as per Facebook's OAuth documentation.
When you create a login url with BaseFacebook::getLoginUrl(), the first thing the function does is to establish CSRF token state1, which creates a hash using PHP's core mt_rand(), uniqid() and md5() functions and also stores the value as a session variable.
When the user gets redirected back to your page the, FBSDK checks if the submitted state matches the state value in the session. If the values indeed match, the state is cleared from the Facebook object and from the session, so all subsequent getLoginUrl() requests would get a new state variable.2
Theoretically you could use your own state value with FBSDK by writing it to fb_<your_app_id>_state session variable before constructing the Facebook-object, as the BaseFacebook's constructor and establishCSRFTokenState() both check if the state already exists in the session.
But that would probably introduce more complexity than is necessary.
see BaseFacebook::establishCSRFTokenState()
see BaseFacebook::getCode()
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.