I want to set session timeout limit for one of the store views in my magento site,
Done too much R&D by surfing several sites, but doesn't come up with any solution
Here is the explanation:
My cookie settings ib admin panel for default config
System->Configuration->Web->Session Cookie management
Cookie Lifetime 900
Cookie Path /
Cookie Domain (blank)
Use HTTP Only yes
And my store view settings
Cookie Lifetime 120
Cookie Path /
Cookie Domain (blank)
Use HTTP Only yes
adminhtml iub2qjrvtcvv46rutus50gngo6 mydomain.com / Session 35
frontend 573ofasrb0l7ems6kr5nv1mo01 mydomain.com / Session 34
frontend 573ofasrb0l7ems6kr5nv1mo01 .mydomain.com / Wed, 03 Sep 2014 09:23:40 GMT 34
Is there any wrong in my settings and why the cookie expiry date is taking as "session" and the cookie is not expiring in 120 seconds.
I find out the solution. In magento cookies time always set in second, you need to convert your date or time to seconds then you will set your cookies in magento according to you.
// Cookies set for one month in magento:
$expire = strtotime(date("m/d/Y, H:i:s A", time() + 60 * 60 * 24 * 30));
$cookies = Mage::getModel('core/cookie')->set('name', 'value', 'expire');
Output: 09/13/2015, 10:43:39 AM (calculate with current date).
Related
Let's say if the bundle.js is 750kb, is it true that if you set it to "never expire" or "expire in 10 years", then the browser doesn't need to fetch that file and therefore can make your website and pageload faster?
(By the way, it is said that Cache-control: max-age is HTTP/1.1 and if it and Expires: are both present, Cache-control overrides the Expires header.)
What if you have a weekly or 2-month release cycle, should you set the Expires header to 1 week or 2 months? I was thinking that with a weekly release cycle, some of your JavaScript or CSS files may stay the same, so it may be good to just set it to expire in 6 months or even 10 years? (because one week later it hasn't changed?)
But what if your file changed but the browser doesn't fetch it? Is it true that if you use the ETag mechanism, or if you use bundle.53ae823.js or bundle.2020-03-12-08.js, then you can "force" it to expire by the ETag being different, or the file name being different? What is a good way to set the Expires header length?
You could use all of those techniques at the same time. If you can include a hash in your filenames and the references to them (example of how to do it in webpack), then you can be sure that you can bust the cache whenever you change something.
Then you could set Cache-control: max-age to 31536000 (a year, the max) because you can trust the file with URI to not change (because of the hash, if the file changes ,the URI will too).
And of course you can implement ETAG in order to enable revalidation of the cache. This will still require a request to be sent to your server/CDN, but will save the user having to download the whole file if it hasn't changed.
There is a nice article on this topic, here.
I have 3 sessions -
1- USER
2- LANGUAGE
3- COUNTRY
When session expires - user is redirect to login and receive a message: "You are disconnected by inactivity"
Its ok. but..
MY ISSUE:
Because I lost session - I lost ALL 3 Sessions - and I don't know the LANGUAGE and COUNTRY of the user.
Then I Always print an English alert (default language)
What I want:
A way to control de timeout of each session. With this I can expires User Session first - and get the other two parameters to print the right language.
Is it possible?
I know how to expires - but ALL sessions..
tks!
Use cookies, so you can control the time, even if the user closes the browser
Response.Cookies("name_cookie")("language") = 1
Response.Cookies("name_cookie")("country") = 1
Response.Cookies("name_cookie").Expires = now + 365
I've got content that changes depending on the date it is requested on, i.e.
the same content will be served when the page is requested at 2018-09-10T00:00 and 2018-09-10T23:59, but different content will be served at 2018-09-11T00:00 (based on the server time).
Is there a vary http header I can set on the content that will achieve this (set by the upstream server)?
Or is there another way of doing this in nginx (ideally only on certain paths)?
Client-side caching is controlled by setting cache control headers.
See http://nginx.org/en/docs/http/ngx_http_headers_module.html#expires for a discussion of the options. It is possible to specify the time of day using the # prefix. So your config would look something like this for setting expiry at 3:30 pm server time:
location ~* \.(css|js)$ {
expires #15h30m;
add_header Cache-Control "public";
}
If your content expired every hour, you could so something fancy like do a time calculation in lua and set that to an ngx variable which is used by expire.
You need to add a "Expires" header, which you can do in Nginx or in your application. The header would look like this, just as an example:
Expires: Sun, 09 Oct 2016 23:59:59 GMT
In PHP you could generate this with:
header('Expires: ' . gmdate('D, d M Y H:i:s', strtotime(date("Y-m-d 23:59:59"))) . ' GMT');
In Nginx you just need to add the following to your location or server block which serves the specified content:
expires #00h00m;
That way the content would expire at midnight.
we have upgraded from WSO2 IS 5.0.0.SP1 to WSO2IS 5.1.0 and we're trying to fix the session expiration. Seems the users is logged in for long time.
On the logon screen we have the rememberMe checked by default (we want users to be persistent for approx 14h = 840m)
What I see is multiple timeout parameters in the identity.xml:
<SessionDataPersist>
<Enable>true</Enable>
<Temporary>false</Temporary>
<SessionDataCleanUp>
<Enable>true</Enable>
<CleanUpTimeout>841</CleanUpTimeout>
<CleanUpPeriod>30</CleanUpPeriod>
</SessionDataCleanUp>
<OperationDataCleanUp>
<Enable>true</Enable>
<CleanUpPeriod>30</CleanUpPeriod>
</OperationDataCleanUp>
</SessionDataPersist>
</JDBCPersistenceManager>
...
<TimeConfig>
<SessionIdleTimeout>840</SessionIdleTimeout>
<RememberMeTimeout>840</RememberMeTimeout>
</TimeConfig>
...
<PersistanceCacheTimeout>900</PersistanceCacheTimeout>
<SessionIndexCacheTimeout>900</SessionIndexCacheTimeout>
but seems the user is logged in even next day (24h)
Now checking the database for the session timeout we see the time_created is even placed far in future (3.5 days).
select session_id , session_type, time_created, operation, tenant_id from idn_auth_session_store where session_id='8d761e3d-c2c8-4a50-b58f-dc20822a0000'
8d761e3d-c2c8-4a50-b58f-dc20822a0000 | SAMLSSOSessionIndexCache | 1467171230156905138 | STORE | 0
Seems 1467171230156905138 is Wed, 29 Jun 2016 03:33:50 GMT
question is - has the time_created used as the expiration timestamp or is it somewhere wrongly converted? If it is used as the expiration date - where is it really configured?
Edit:
what I see from the code the value is (cannot we just use a simple ms timestamp?):
currentStandardNano = currentStandardNano + (currentSystemNano - FrameworkServiceDataHolder.getInstance().getNanoTimeReference());
this effectively move the timestamp in future for the value of the server's uptime. Is there a reason for it?
Thank you for any insight
This was identified as an issue in Identity server 5.1.0 and has been fixed for future releases. This has been discussed here.
I have a ACL+auth driven app. Everything works fine but I discovered that user is logged out after a random period of time. After doing some research I discovered that the cookie set once doesn't change it's expiration date on page refresh. So it goes like this:
I set up manually expiration time to 1 minute (Security.level low (with some changes in cake/libs) and timeout 60)
19:00:00 - user loads the page - cookie is set up
19:00:05 - user logs in (cookie doesn't change the expiration date)
19:00:30 - page refresh (cookie doesn't change the expiration date)
19:00:55 - page refresh (cookie doesn't change the expiration date)
19:01:05 - page refresh - user is logged out... (cookie expired after 1 minute)
So the problem is the user gets logged out after 60 seconds from setting a cookie in instead of 60 seconds of inactivity. Does CakePHP deal with cookie files automatically? Or do I have to take care about it myself?
All I did is set up a cookie name in config/core.php and setup auth. I don't have any cookie handling function, but the cookie is created itself - correctly, just isn't updated
I had the same issue and countered it with the following code which is called on every page load and ajax call.
if(isset($_COOKIE[Configure::read("Session.cookie")])){
$session_delay = Configure::read("Session.timeout") * (Configure::read("Security.level") == "low" ? 1800 : 100);
setcookie(Configure::read("Session.cookie"), $_COOKIE[Configure::read("Session.cookie")], mktime() + $session_delay, "/");
}