Posted by j0k3z on June 11, 2010 at 12:55am
10 followers
Jump to:
| Project: | Domain Access |
| Version: | 6.x-2.5 |
| Component: | User interface |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
about half of my users are having issues with logging into my site since I added the domain access module. In the logs it looks as though when some users login they are successful logged in but taken again to the user/login page when shows an "Access deined" error since they are already logged in. I cant seem to figure out why only some users are getting this and when I try and register a new account myself or login to another account it always works without error for me.
Comments
#1
What is you domain structure? Are you sharing cookies across a top-level? e.g. "$cookie_name = '*.example.com' as noted in the documentation?
#2
I use a common domain like example.com ny.example.com la.example.com and I am using shared cookies so users can login across domains.
Currently my cookie domain says "$cookie_name = 'example.com';" without the star or period before my base domain --- is this what is causing the issue?
#3
I've changed the base domain to .example.com and I am still seeing the same issue in my logs for some users.
#4
They log in succesfully but are taken back to user/login page which of course gives then an access denied message.
#5
What other modules are you using that affect login? This is not a core DA issue.
#6
I am using Login Tobaggan to allow users to sign in with their email addresses and nothing else that I can think of.
#7
That's the likely cause of the issue, then.
#8
Disabling the module doesnt seem to fix anything. I think something else must be causing the issue. Its really strange since I can only see the access denied errors in my logs and cant seem to run into it myself
#9
I have a similar issue, except on a local setup. so far only user/1 account is created, which, was returning acess denied. now white screen.
I will double check settings.php and disable modules via phpmyadmin and report back.
#10
I have methodically worked back to a default drupal 6.17 install, but, nothing to report.
#11
Wait, what does this mean?
I've changed the base domain to .example.com. You can change $cookie_domain but not $base_url. You should never hardcode $base_url when using DA.#12
I meant cookie domain. Mine is currently '.example.com'
#13
Ive been playing with settings for days and cant seem to figure it out.
#14
Hi,
I just ran into this same problem. I had my cookie_domain set to "www.domain.com". To fix it, I simply commented out the cookie_domain setting since it didn't seem to be necessary for my particular configuration.
Note I also had to clear the cache on my local browser to fix some subsequent errors returned by the securepages module.
#15
Using D6.17 and lot of modules.
I ran in to this issue too. In FF3.6 i have same problem with returning to same page without loging in.
But in chrome and safari i do login, but only on one subdomain. And i can login on each test.example.com , test1.example.com , ect by different accounts. And switching subdomain , switches the accounts too (or just keeps the different accounts logged on every subdomain).
Looks like some trouble with cookies.
The only thing i remember to change is updating:
cck, views, link, token to last versions and lightbox2 to last dev.version.
But i'm not sure that it is something to do with this modules.
i'll try to investigate, to give more information on this.
#16
Well, i fixed it by checking the settings.php
In my case i had $cookie_name = 'example.com' without a dot in front of domain.
changing it to $cookie_name = '.example.com' and clearing cache and cookies in browsers fixed the problem.
The strange thing is that i used it without a dot for more than a year and only now it made some troubles.
#17
I wonder if this is new behavior in 6.17?
#18
My cookie name is correctly set to '.example.com' but I am still getting this error for some of my users.
#19
Are they blocking cookies? Are they getting logged in at all?
#20
They are logged in but for some reason it sends them back to the login page right away which shows an access denied message since they are already logged in.
#21
That is not coming from DA core. What else do you have installed?
#22
OK I think there is a lack of proper communication/explanation/understanding here. As agentrickard states, this issue is not coming from DA core. When one accesses a Drupal site for the first time, Drupal core creates a session cookie so that the user's browsing session can be managed & tracked by Drupal core and contributed modules. This session cookie exists even before a user logs into the Drupal site. I would say the first thing to do would be to ensure that the browser is not rejecting/blocking this session cookie before making any attempt to log in.
If the browser is accepting the session cookie then the next step would be to confirm the behaviour that occurs when one logs in. By default, when one logs into a Drupal site (whether or not DA module is installed) Drupal core validates the login information and, if verified, updates the session information and redirects the user to their user profile page. Now, there are modules (i.e. Login Destination, LoginToboggan) which allow you to override this default redirection behaviour and specify a different page to redirect to after Drupal authenticates a login.
Also, and again, this is a Drupal core behaviour, not a DA module behaviour, Drupal sets the domain for the session cookie to whatever domain is being used to access the site, UNLESS you specify a value by setting the $cookie_domain value in settings.php. So, when using DA module and say you have four domains configured, say example.com, one.example.com, two.example.com and three.example.com, then you MUST set the $cookie_domain variable to .example.com in order for the session cookie created to be available across each of these domains, no matter which domain you login from. So, if you decide to instead set $cookie_domain to say example.com, i.e. without the leading dot, and you attempt to login from two.example.com then the login WILL fail and you will be redirected back to the user login form on that domain. Why? Because a cookie created for example.com is NOT available at two.example.com UNLESS the cookie value is .example.com (put simply, the leading dot makes sure the cookie is available on example.com + ALL subdomains of example.com).
If of course you do not set $cookie_domain to any value then as I eluded to before, when you access one.example.com Drupal core creates a session cookie for the domain one.example.com, when you access two.example.com, it creates a session cookie with a domain value of two.example.com, etc. These cookies will therefore each be domain-specific which means if you login at example.com you will still have to login at one.example.com too because example.com's session cookie will not be available on one.example.com's session cookie.
So, having said all that, the solution to this issue is simple:
1) Make sure that the browser is accepting cookies from Drupal in the first place, i.e. from the first entrance into the Drupal site (the name of the cookie should follow the standard PHP session variable naming convention since Drupal uses PHP's built-in session handling, so it will probably be something like SESSa495ff..... or SESS...whatever).
2) Check if the site has any Login redirection modules installed/configured to redirect users after logging in.
3) Make sure you set the $cookie_domain variable in settings.php to ensure that logins to the site are "propagated" across the domain and all subdomains, so you only have to log in to one domain to be logged in to all.
I really don't think there's any more explanation that can be given than this. Hope all of what I've said makes sense. All the best with tracking down the source of your issue.
#23
Thanks for you're explanation ispheretechnologies. I think I understand the problem with domains and cookies, but I still have the same problem as described above. I am using DA and no login redirection modules. Since a week or so, the problem has been noticed by different users. $cookie_domain was set to 'www.example.com' and now I changed it to '.example.com'. But to no avail.
I can log in on www.example.com/user and then get redirected to www.example.com/users/uid.
When I log in on domain1.example.com/user, I get redirected to domain1.example.com/users/uid and I get an access denied message.
When I'm logged in on www.example.com and then view a page on domain1.example.com, it seems the session is deleted. Going back to www.example.com, I am not logged in anymore.
--
Edit: I just noticed, that $cookie_domain is still set to 'www.example.com' because I don't have write permissions for settings.php. I'll try to change that and then report back. The behavior I described thus is for
$cookie_domain = 'www.example.com';.#24
not really a fix, but one possible solution can be found here http://drupal.org/node/838768
#25
Actually Im not sure if that completely fixed the issue because in my logs I still see some users hitting the login page over and over getting the access denied message.
#26
Then I suspect they don't accept cookies.
#27
Well, I disabled cookie to see if that might be the issue -- I was not able to login with cookies disabled but it did not give me the access denied message in the logs like I am seeing with this issue. So im guessing its not related to not accepting cookies but possibly something else instead.
I've been reaching out to the users who I see in my logs getting this error and attempting to contact them for more details about what their settings are but so far I am not getting any responses. Its pretty hard for me to track the error down since I dont run into it myself.
#28
as mentioned http://drupal.org/node/824548#comment-3156680 it's not really a fix, but handles the situation more elegantly i.e. the users don't see access denied error but they are gracefully taken to the home page of the site.
#29
Just to be sure, users do need to 'access user profiles' in order to view the user page. The access denied might be coming from that.
#30
I think that this problem relates to Drupal core upgrade from 6.16 -> 6.17 because all my multisite -sites, which had cookie domain set as "domainname.com" without leading dot, went bust. I would recommend to somehow notify users about these changes (at least I didn't notice any info about this before upgrading to 6.17) because all these blown sites definitely affect on Drupal's general reliability.
If someone else wanders here and is affected by the same problem as my sites, the solution was either
#31
That is already documented in the module INSTALL.
#32
adding a leading dot (.) does not solve the problem for me and I cant comment out the cookie domain line or my users wont have access to other subdomains on my site
#33
You can't hard-code cookie-domain. It just won't work. You need a single-sign on soluition, like OpenID.
#34
@str1, avoiding the problem you faced is in fact documented in the DA module INSTALL file so IMO that does not reflect on Drupal's general reliability or DA's module reliability.
As for the problem being discussed in this issue I suspect the source of the issue is related to either improper permissions settings, prohibitive browser cookie settings or incorrect $cookie_domain value in settings.php.
I've used DA and a number of DA-related contrib modules on a handful of sites and never had users encounter this problem. Just to be sure of what agentrickard already asked, does the role for your users have the permission 'access user profiles' set?
#35
For me I allow both anonymous and authenticated users to see user profiles so that is not the issue. I have also made sure my cookie_domain value is correct (and I know it is because most users are not having any issue) - so that leaves some crazy browser cookie settings possibly messing things up. I cant seem to figure it out though.
#36
Well - clearing cookies fixed it for me. Thanks ispheretechnologies - I didn't get half of the stuff you were going on about but it was enough for me to have a go at clearing the cookies and voila .... problem solved (well - for now anyway)
I've just finished an upgrade from 6.11 or so to 6.17. I've also had a fiddle with the minimum cache settings and while all OK from my home computer, trying to login from work's computer was throwing up "Access Denied" errors for any username. No stuffing around with the settings.php file fixed anything.
#37