Why do i have to use some persistent-login module to make my users login into Drupal 6
for longer period of time.
Why changing php.ini or settings.php doesnt works ?
from a "webtools" I see my cookies being expired in next day, but after few hours it happend to log me out.
This is like spontagenious action, no pattern to follow / predict.
why this "keep-alive" login exists in drupal ??
You do not have to use the persistent module to achieve longer log in periods. You can simply adjust the ini_set() calls for the session.* PHP settings in your Drupal instances settings.php file (especially session.cookie_lifetime and session.gc_maxlifetime).
If adjusting those does not work for you, you should ensure that your server configuration allows overriding them from PHP.
Also, Drupal uses the standard PHP session storage mechanisms - if there are other PHP apps running on the same server, they might interfere with your session lifetime settings, depending on storage path configurations. See point 2 in this answer for information on that.
The persistent login module aims to make the configuration easier, but especially adds more features, as e.g. allowing a general remember me option while still requiring reauthentication for sensitive operations (like changing the password) to minimize the risks associated with long login periods.
Check this article linked from the modules project page, as well as this article linked from there for some in depth explanations concerning the handling of persistent logins.
Drupal overrides the internal php session save handler in include/bootstrap.ini and has some non standard session code there. Haven't followed it through though.
Beyond that Drupal's settings.php will override php.ini.
Related
On a large webapplication, I want our customers to be able to enable/configure their own sigle sign-on (SAML) identity provider. Each customer has it's own specific subdomain allowing our application to determine which firewall should be active.
However, I don't want to manually configure each new firewall and clear the cache before changes are taken into effect. Now I read about dependency injection, extensions, compilers and all that, but I just can't seem to find a way to load dynamic firewall settings from the database and apply them. Any idea how I would do this?
FYI, I am using the SamlSPBundle for SSO.
Thanks!
I may have figured this out just moments after setting a bounty! ;)
Symfony2 security allows specification of a request_matcher on a per-firewall basis:
http://php-and-symfony.matthiasnoback.nl/2012/07/symfony2-security-using-advanced-request-matchers-to-activate-firewalls/
Custom RequestMatchers must implement a single method that returns true or false based on the Request object. I think this could be used to activate a firewall dynamically. As long as you have a finite number of firewalls (I do), then a custom RequestMatcher could solve your problem.
I'm using nginx, memcached and APC for all my sites. What I host is a wordpress site, a vBulletin forum and some other sites.
I've set up nginx and memcached so that nginx first checks the memcached server to see if it has an entry for the full page, if it doesnt pass the request along to PHP and cache the full page - then display it to the user, see link for configuration: http://pastebin.com/ZFSrA9e5
Currently the vBulletin forum is using the "$config['Datastore']['class'] = 'vB_Datastore_Memcached';" and the WP blog is using the Memcached Object Cache (http://wordpress.org/extend/plugins/memcached/)
I am only caching WP as the full page in memcached (as explained above) at the moment to see if I run into any issues - so far so good.
What I want to achieve is good loading times and low load. The issues I've ran into/questions I have ran into are these:
How do I know that for example a user logs in for the first time, memcached caches the request for the first user. Then the next user comes and memcached serves the cached page for the first user - does anything take this into account/prevent this?
How/when will memcached/nginx flush the full-site cache in order to update the cache?
Am I recommended to run both APC and memcached? As far as I'm aware; memcached caches small values and apc caches the compiled PHP code, correct?
Would be awesome if someone could enlighten me on these questions.
1) Your cache response solely depends of this:
set $memcached_key "wordpress:$request_uri";
So each cached-entry depends only of URI and user auth information does not make sense. Second request will be same as first one because it will have same memcache keys. If you want to store separate cache-keys for each logged user you'll need to set more distinct key, something like this:
set $memcached_key "wordpress:$request_uri$scheme$host$cookie_PHPSESSID";
2) This depends of WP-plugin. Nginx never flushes the cache, to make force-flush you'll need to restart memcache.
3) Yes, both of them do different things, APC caches compiled PHP code, so it dont have to compile each time with each request (it only recompiles with server restart or when php file is changed). Memcache stores some portions of page or the whole page (your scenario) in memory and when KEY provided by nginx found in memcache, PHP is not even involved - whole page serves directly from memcahced memory.
hope this helps)
some users of my site contact me and said that they have a problem to see their information. the problem is that they see information of other users !
i developed my site by asp.net mvc 3 and asp.net membership. when i logon by that username and password everything is ok. i think something happened like ISP cash or network cash for them ! because other users hasn't any problem. i check my code and no problem find !
ISP cache or network cache can not cause this problem. you should search for this problem in your code. also authentication method is not in charge of this problem.
the problem maybe because of session or cookie expire. when a session expires, your app may look for a default data (for example form other user roles) and present it. so should look for such security holes in your application.
another problem maybe because of caching problem in your code or asp.net cache ! caching users data and show it to other users!
I once had something like this happen on an ASP.NET page. Turned out the problem was that I had caching enabled on one of the pages and so the user could see the information on a previous user.
The most likely scenario is that you are caching results server-side and not varying the cached information by the user. Either you need to vary the caching by the parameter that is related to the user or by the user themselves (using VaryByCustom).
Example:
[AuthorizeByUser( Roles = "Admin" )]
[OutputCache( Location = OutputCacheLocation.Server, VaryByParam="*", Duration = 500 )]
public ActionResult Profile( int id )
{
...
}
Varying by all parameters here means that each value of the id parameter will have a different cache entry. Here we assume that id is related (perhaps is) the user's id so each user will have a different cached entry. Note your security (the AuthorizeByUserAttribute) would also need to be set up so that it won't serve up cached results to unauthorized users. Here I'm assuming an implementation derived from AuthorizeAttribute which verifies that the user is in the "Admin" role or has a user id related to the id in the method signature. See my blog post on custom authorization for ideas on how to do this: http://farm-fresh-code.blogspot.com/2011/03/revisiting-custom-authorization-in.html.
I had this exact problem when we brought in the source code from another digital agency. We took their codebase and added more features to it. Testing went fine on both dev and staging and we went ahead to publish it.
As soon as the site went live, we had a lot of users complaining that they were seeing other users’ information as soon as they logged in. We couldn’t replicate it because it happened intermittently.
We thought it could be static method. Replaced all of them by instantiating an object and call that method, the problem was still there.
We thought it was Singleton pattern. We removed them but the problem was still there.
It took us weeks to figure out the culprit. The issue was the load balancing feature set up by the previous digital agency. It was working fine on their two load balancing servers. The problem started as we were hosting on one server. As soon as we turned it off, the problem went away. However, the damage was done. We lost a lot of customers as they didn’t trust our system anymore.
It happened eight years ago but I still have nightmares about that issue from time to time.
Quick question - Is there any simple way (module perhaps?) to set the admin account to stay logged in forever?
I admin a bunch of Drupal sites and am getting really tired of constantly logging in after whatever interval it logs out automatically.
Use http://drupal.org/project/autologout
You can set the administrator to automatically logout after an insane amount of time (so it effectively becomes forever). Other users can be excluded from this setting so it does not apply to them.
Enable the module and checkout the settings at /admin/settings/autologout
This method is better than tweaking the session expiry related ini options in settings.php because then they apply to everyone and not only administrators. So it would have the bad side effect making everybody stay logged in forever.
P.S. these are the ini settings that determine session expiry in Drupal in settings.php
ini_set('session.cookie_lifetime', 2000000); // in seconds; approx 23 days
ini_set('session.gc_probability', 1);
ini_set('session.gc_divisor', 100);
// see http://www.php.net/manual/en/ini.list.php for explanations
No. The session is a function of your PHP installation (session controls) and your browser (it is a cookie-based session). For security concerns, I would highly recommend not doing that anyway.
I have an application where, in the course of using the application, a user might click from
virginia.usa.com
to
newyork.usa.com
Since I'd rather not create a new session each time a user crosses from one subdomain to another, what's a good way to share session info across multiple subdomains?
You tagged this with ASP.NET and IIS, so I will assume that is your environment. Make sure you have this in your web.config:
<httpCookies domain=".usa.com"/>
If your 2 subdomains map to the same application, then you are done. However, if they are different applications you will need to do some additional work, like using a SQL Server based Session storage (and hacking the stored procedures to make sure all applications share the same session data) or with an HttpModule to intercept the application name, since even with shared cookies and the same machine key, 2 applications will still use 2 different stores for their session data.
Track your own sessions and use a cookie with an appropriate domain setting, ie. .usa.com.
Alternatively, if you're using PHP, I believe there's a setting to change the default domain setting of the session cookie it uses, that may be useful too.
The settings you're looking for are:
session.use_cookies = 1
session.use_only_cookies = 1
session.cookie_domain = .usa.com
I recently went thru this and learned the hard way. Localhost is actually considered a TLD. Cookie domains require at least a second level domain - test.com. If you want cookies to work for a domain and all it's sub-domains, prefix with a '.' - .test.com.
When running/debugging locally, setting a domain of localhost will fail, and it will fail even if the domain is set properly because visual studio uses localhost by default.
This default localhost can be changed in the project properties so that the project will actually run at cookie domain test.com. Essentially, if the address in the browser matches , you can get it to work.
My issue is documented here: Setting ServiceStack Cookie Domain in Web.Config Causes Session Id to Change on Every Request
Hope this helps.
If you're using PHP, one hack would be to make a little include script (or two) to do the following:
1 Serialize your $_SESSION array
2 Pass that string as a hidden input, making all your links to those buttons in separate forms using POST.
3 Also include a boolean hidden input to let your script know whether it needs to use the current session or unserialize $_POST['session']
4 Deploy this across your site, calling things where appropriate
I wouldn't do this if there's actually a sanctioned way to transfer a session. I hope you've at least considered using cookies.
Matt's answer is definitely the way to go if you have multiple subdomains pointing at the same IIS app (which is exactly the situation I have right now, using wildcard DNS and then doing subdomain 'sniffing' on the receiving end).
However, I wanted to add something that I experienced in case anyone is finding that this is not working for them. Setting the httpCookies line alone didn't do it for me, I had to add a machineKey entry into my web.config file:
machineKey decryptionKey="12...D1" validationKey="D7..8B"
Particularly odd since I am not in a web farm setup (unless AWS/EC2 is effectively acting as such).. As soon as I did this, it worked like a champ.