I tried this using jwt-auth, but the thing is token gets expired. I want to remember the user with token that never gets expired. Is their any possible way to do it in Laravel 5.2.
Should I send email and password for each request to api instead of saving session and token.
I will implement this way:
If the user selects Remember me, set the ttl to a longer time ,say 1 year OR month. To do this we need to publish
php artisan vendor:publish --provider="Tymon\JWTAuth\Providers\JWTAuthServiceProvider"
Then we can override the default ttl value which is 60 mins to our desired value.
$jwt = \Illuminate\Support\Facades\Config::get('jwt');
$jwt['ttl'] = 60*24*30; // 30 days
\Illuminate\Support\Facades\Config::set('jwt',$jwt);
Hope this helps!
Related
When a user's password is updated I want the Security stamp value to be updated every time that happens. I believe that is how Security stamp works from my research.
I place this code in the ApplicationUserManager.cs but this isn't working:
private static string NewSecurityStamp()
{
return Guid.NewGuid().ToString();
}
What and where do I need to get the security stamp value to change each time an update is made to the user's account?
That is what happens. However, the security stamp is only re-validated on an interval (every 30 minutes, by default), to reduce the number of database queries being made. You can lower this interval, even to zero, which effectively makes the stamp be re-validated with each request. However, that will increase the chatter back and forth to the database.
services.Configure<SecurityStampValidatorOptions>(o =>
{
// WARNING: this will issue a query for every request
// You might want to rather just compromise with an interval
// less than 30 minutes (5 minutes, 10 minutes, etc.)
o.ValidationInterval = TimeSpan.Zero;
});
An alternative option is to simply log the user out after such a change. If the goal is to simply make them re-login, that should do the trick much better. Just inject SignInManager<TUser>, and then call SignOutAsync on that instance. You'll need to redirect the user afterwards. That could be directly to the sign in page or to some area of the site that is protected, which will then cause them to be taken to the sign in page to authenticate. In either case, a redirect is necessary to have the auth cookie actually be deleted.
Module send only Ajax process to module controller every 5 seconds. After few minutes prestashop automatically logged out employee. How I can keep stay loggin?
In your ajaxProcess function, do this:
$cookie = Context::getContext()->cookie;
$cookie->write();
This will refresh the duration of your admin cookie when your ajaxProcess returns, that is when the headers are sent which is how cookies get set.
Optionally you can include this code above the write() call so that the last activity time is also recorded
if (!Tools::getValue('stay_logged_in')) {
$cookie->last_activity = time();
}
You can see this code in action in /controllers/admin/AdminLoginController.php
I am running into an issue with one single user's refresh workflow for Google OAuth. I am correctly scoping for offline access and am storing that. Every 60 minutes, when needed, I retrieve a new access_token. Code has not changed, but what is odd is that when he first went through the authorization process it worked for about 3 days. Then we were running this issue, so I made him revoke access and go through the authorization again. This only lasted for 3 days once again.
client_id ="xxxxx.apps.googleusercontent.com"
client_secret ="yyyyyyyy"
refresh_token ="zzzzzzzz"
response = oauth2a.RefreshToken(client_id,client_secret,refresh_token)
def RefreshToken(client_id, client_secret, refresh_token):
params = {}
params['client_id'] = client_id
params['client_secret'] = client_secret
params['refresh_token'] = refresh_token
params['grant_type'] = 'refresh_token'
request_url = AccountsUrl('o/oauth2/token')
response = urllib.urlopen(request_url, urllib.urlencode(params)).read()
return json.loads(response)
The response is always {u'error': u'invalid_grant'}. I have attempted this on three different machines, so the NTP time sync is not the issue as well. All other user's refresh works fine. I am also never asking for a refresh_token again, so I know I'm not running into that 25 refresh_token limit. This is looking like it's a bug on the gmail side, is there any way that I can proceed to try to fix this?
I was surprised I couldn't find a good answer to this out on the interwebz, so here we are.
I'm setting a FormsAuthenticationTicket to expire after a week. This is used in tandem with a "Remember Me" setting we feature on our login form. This is being accomplished by :
var cookie = new HttpCookie(FormsAuthentication.FormsCookieName);
// set the auth token expiration to a week
var authTicket = new FormsAuthenticationTicket(1, user.Email, DateTime.Now, DateTime.Now.AddHours(168), true, userData);
var encryptedTicket = FormsAuthentication.Encrypt(authTicket);
cookie.Value = encryptedTicket;
cookie.Expires = authTicket.Expiration;
With this, I've also extended our session timeout, as many of our users keep the application open for equally long periods of time :
<forms loginUrl="~/account/sign-in" timeout="10080" name="t5S4U4Y152" domain=".xxxxxxx.xxx.xxxxx"/>
My question :
I've been asked to make this a non-expiring cookie, such that as long as the user retains it, they'll always be logged in - more or less an infinite login. Is there a default value I can set the ticket and timeout to in order to achieve this?
Yes, I could set both expiration's to something like 50 years from the present, but I'm wondering if there is a cleaner or more suitable approach?
No there isn't any value you can set the expiration so it is infinite. You'll just need to set it to something really long.
As you know, if you do not set an expiration the cookie then only lives for the length of the session (when the browser is closed), which is definitely not what you want.
You can also use slidingexpiration=true so that whenever a user comes back to the site, the expiration date on the cookie is refreshed to be Today + Timeout instead of DateInitiallyIssued + Timeout
My thinking was that Symfony2 would extend the ExpireAt on each page request made during the authenticated session. So if the timeout was 100 seconds and you made a page request, the new ExpireAt would be time() + 100. This "use it or lose it" authentication functionality is similar to what you get on a banking website.
The default functionality seems to be when the session timeout is set to 100 in the config.yml, the user only has 100 seconds to do what they can.
I don't think this will be to hard to implement but where should it be done? My first guess is in the isEqualTo method. Once you can determine the user is authentic you can re-up their expireAt. Or does the cookie need to be modified?
The answer lies in the refreshUser method of the UserProvider and the isEqualTo method of the UserClass.
The isEqualTo method tells the user provider whether to refreshUser(UserInstance user).
Step1 : isEqualTo() returns false; (as your understanding grow, so can this logic. But essentially, this triggers refreshUser().
In all the basic user provider examples, the refreshUser & loadUserByUsername are identical. The to do what I'm talking about, the refreshUser() needs to be a little different.
Step2 : modify refreshUser(UserInterface $user). What's being passed into this method is the original userClass. So the refreshUser is responsible for syncing the expiresAt or credentialsExpireAt
I use this logic in my refreshUser() to either extend the expiration date OR set it to the original expiration date (which is expired):
if( time() > $user->getCredentialsExpireAt() ){
$refreshedUser->setCredentialsExpireAt( $user->getCredentialsExpireAt() );
}