I'm using Drupal 7 with Varnish. Recently I noticed that the login and sign up blocks are not working for anonymous users. When a user tries to login or create an account via the blocks the user is just redirected to the same page however the new accounts are being created and the user session is also created. Is worth mentioning that if the users tries this via sign in/sign up page they don't have any issues. The problem happens only when using the blocks.
I'm thinking the issue could be related to Varnish. I tried disabling the Varnish module but the issue is still there. Also I tried using the ESI module so that blocks will not be cached but that didn't do anything.
Does anyone has an idea what may be causing this problem?
I guess there's a missing "Vary: Cookie" header in the original response, but it's hard to tell without the full headers and VCL.
ESI module won't affect login block AFAIK
Related
I have a website in production server, asp.net webforms using Asp.Net Identity system.
Sometimes, when users tries to login, it redirects then back to login page after successful authentication thereby denying them access to user dashboard and other secured pages.
The temporary solution to this is for me to Recycle Application Pools in the hosting server (via plesk). But it appears again after some time. Sometimes before 24hrs or more.
The issue most often occurs when multiple users are getting logged in at a range of time... From my observation.
I don't know the main cause of the issue and I'm seeking a permanent fix to it. What could be the issue? How can I resolve this?
Useful hint:
After authentication at the login page, I usually create a response cookie which holds other value which I use to keep track of the user. If the cookie expires, I redirect the user back to login. I usually check for existence of this cookie on the master page for each page load. So I don't know if this could be a possible cause. If it is, whats the best practice to employ?
I've tried checking the cookies being set if it's the possible challenge, but no success.
I'm just curious if you can bypass the login into a asp.net website, which to let yall know, I have no control of using a unique url?
I have login credentials to the site, and tried using those to do this but to no avail.
So is this possible? Only thing I could think of was
http://username:password.awesomesauce.com/login/login.aspx
FYI I can log in fine, I just need this to login to the site via a 3rd party app. It is a major pain to login everytime with the app and sometimes many of the functions fail because its screwy with keeping an authenticated login
No, this is not normally possible.
This would be a very specific custom case - there is no standard for this as all logins are different, and authentication methods with databases etc. are all different.
FTP can work like this, but that is because the authentication is part of the protocol whereas in a web form it is not.
I used a firefox add on called Live HTTP Headers 0.17 to follow the url actions as it logins into the site. After turning on the capture option I logged in and it gave me this
Then I took the contents from the Content-Length catagory and appended it to the url like so
https://www.TROLLFACE.com/login/login.aspx?__LASTFOCUS=&__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwUJMTI2OTI3NTE1D2QWAmYPZBYCAgMPZBYMAiAPDxYCHgdWaXNpYmxlaGRkAiEPDxYCHwBoZGQCJg8WAh4LXyFJdGVtQ291bnQCGhYCAhkPZBYCAgEPFgIeBXN0eWxlBQtib3JkZXI6MHB4O2QCKA8WAh8AaGQCKg8PFgIeC05hdmlnYXRlVXJsBRZqYXZhc2NyaXB0Om9wZW5DaGF0KCk7ZGQCOQ8PFgIeBFRleHQFKUNvcHlyaWdodCAmY29weTsgMjAxMiBCIE8gWCBQYXJ0bmVycywgTExDZGQYAQUeX19Db250cm9sc1JlcXVpcmVQb3N0QmFja0tleV9fFgEFGGN0bDAwJGJ0bkNoZWNrSW52ZW50b3J5MdYH4EkMQWCgv%2FEOSMLJPNZ21rMa&ctl00%24cphMain%24txtUsername=USERNAME-GOES-HERE&ctl00%24cphMain%24txtPassword=PASSWORD-GOES-HERE8&ctl00%24cphMain%24btnLogin=Log+In
Please note the USERNAME-GOES-HERE and the PASSWORD-GOES-HERE
So far it works every single time, effectively skipping the login.
I'd like to be able to use these "best of breed" opensource solutions, with the only requirement of some sort of single-sign-on between the different sites. I don't want my users having to log-in in 3 different places, so I though it could be possible with OpenId.
Has anyone tried something similar?
OpenID will not avoid the problem of having to sign in 3 separate times. It was allow the user to share the same login credentials between the sites, but they will have to actually log in to each of the three systems. If that is not a problem, go with OpenID. If it is, you have two options:
Use an LDAP server to authenticate on all three sites. I think all three software packages have modules/plugins for LDAP (Drupal, Moodle, MediaWiki). Once you have the LDAP server running, the rest should be easy.
Write custom modules/plugins for each platform that authenticate against a single database. Maybe you could use the Drupal database as the primary one, and have MediaWiki and Moodle authenticate with that. So, effectively, the user will only have an account on the Drupal site, but will get access to all three. This is basically the same idea as an LDAP server, but might save you some overhead and complication.
There is also the Moodle Integration module for Drupal that attempts to accomplish the same thing, only without MediaWiki in the mix. I would check that out.
Good luck!
here are three possible solutions: (1) sigle sign-in site, (2) inject login/register forms into all sites using server site includes - SSI and (3) - ajax.
Single sign-in site.
suppose you have site1.domain.com and site2.domain.com and you want to login/register at both simultaneously. Probably the easiest way to do it will be to create another domain e.g. login.domain.com that will do the job. Your login/register application will need access to databases for site1 and site2 and/or their api's. Since login status usually resides in the cookies, your login application will need to set those login cookies to both sites simultaneously (on successful login/registration) and delete on logout.
To set cookies for all sites from login.domain.com - all of the must sit on .domain.com and cookie domain parameter must be .domain.com
If your solution needs both api access (to the other applications) and access to the same database by several applications - you may need to deal with database transactions. This is because new registrations won't be visible on other sites until transaction is committed - so for example - you can not call api from within login code to retrieve cookies before committing the transaction with the new registration.
One important detail. If you already have users separately registered at site1 and/or site2 but not on both your signon site will either have to handle those cases or you'll need to sync registrations manually yourself upon deployment of your new registration system. Manual fix won't be possible when extra user input is required to complete the cross-site registration. This point also becomes important when you add new sites requiring some new user input for the registration.
Finally, carefully choose domain name handling OpenID. To the best of my knowledge it is impossible to transfer openid endorsements across subdomains without users consent - please correct me if I am wrong. You don't want to ask users to re-register just because you decide to rename the sub-domain.
server side include (ssi) method
Another solution is to inject those forms via sever-side includes into all sites. This may be considerably harder and will depend on the type of webserver in use and will work slower.
A pre-requisite here is that all your applications run on the same subdomain - so that openid works for all of them.
I've once built common user registration for MW (php) and cnprog (python/django).
My solution was to display the same exact registration form on the wiki and the forum site, while generating and processing this form with django. I did it this way because wiki and forum "skins" are so different that I did not want to surprise visitors with the dramatic change of site appearance when they go to the registration page. This is complicated and I will not do it again :) and instead would go with single sign-in method.
in order to display django output through mediawiki I've created a wiki extension printing apache "include virtual" call to glue django-generated content with the wiki output. This comes with problems.
Apache include virtual on my installation cannot POST to subrequests and cannot pass cookies from subrequests and cannot pass redirect responses (all http headers will be thrown out) to the upstream user requests.
So I've added "was_posted=true" to mark the posts for django and a secret code to prevent cross-site forgery. To get the cookies out - had them printed with cookie_morsel.output_js() in python. So javascript must run on the client for this to work. Any redirects will have to be done with javascript too. Extra work will still be needed to upload files (like avatar picture).
So single sign-on may be the best solution.
ajax may be a neat way around - just build forms in all of your sites with javascript and submit them via ajax. Will work fast and will not break appearance of your various sites,
but this won't please the folks allergic to javascript.
Actually, the only method that does not require any javascript is single sign-in site.
Posted this because I've spent enough time building this thing for MW and django - an hour of typing did not make a difference :).
I have an asp .net webforms app that uses forms authentication. For a small number of users we have a problem where they log in, they navigate to a couple of pages and then they are asked to log in again. Once logged in for a second time they seem to be able to stay logged in as expected. They shouldn't be asked to login the second time.
This is a single server, no web farms, nothing tricky.
This only happens to a few users, but it does seem to be all users from the same building. I am unable to replicate this and at this point might even start to deny that t was happening if one of our trainers hadn't watched it happen to a couple of customers.
Has anyone else seen anything like this?
I am also seeing a lot of "Membership credential verification failed." errors in the event log. This may be related, but all the googling I've done seems to point to web farms and the like, not a single server.
UPDATE
There is no proxy server, the IIS server and the browser (IE8) are both on the same machine.
The AV software installed is Symantec Endpoint, on one machine, on the other the user didn't have any AV at all (AV Fail!).
The browser is IE 8 with no frills, not a single addin that didn't come with the default installation.
Both session and user login time-outs are set to 30 mins and the problem happens within 1 min of the user logging on.
Logging shows the user to only have one IP address.
I have tried the sessionMode in all it's variations, this doesn't seem to make any difference.
Something has to be causing ASP.NET to think these users have new sessions or their authentication cookie is getting invalidated. Here a a few things I can think to check:
Are the users accessing the site through a proxy server? One of our customers has a proxy that will sometimes close all open connections causing ASP.NET to see the session as new.
Could an overly agressive anti-virus, anti-spyware product be "eating" the session authentication cookie?
Do they have a cookie manager browser add-in that is causing the authentication cookie to disappear or change?
Sounds basic but I've seen this happen because of site timeouts being set too short. If the user sits on the page for longer than the timeout, they will be forced to logon again. And this could be specific to a page when that page presents a large amount of data that takes a while for them to go through.
One other thing I just thought of, have you allowed multiple worker processes for the ASP.NET process (aka web gardens)? If so, the same constraints as with a web farm would apply for authentication.
Crack open Fiddler from the problem user's PC and see what's getting passed in the headers. My bet is on a proxy server and or networking issue.
Are the users possibly coming from a dynamic ip address? I've seen problems where the users sessions get messed up because the IP address that they're accessing the site from changes for some reason.
Are the people this is happening using a browser that's somehow different (different browser, different version, different extensions)? That could be a clue.
In general, when the problem is somewhat reproducible or at least predictable, I use Http Fiddler. Install it on a client machine, turn it on, and start browsing (this works via a system proxy - so it'll work for firefox, IE and any other proxy-supporting browsers alike). Fiddler will record all http traffic between client and server, and you can then peruse such a session later on to find any oddities.
It's a long shot, but one thing I've seen happen occasionally that can lead to these sorts of unpredictable errors is scripting parallelization issues: sometimes buttons + links have onclick handlers which cause a post-back. If you have several such handlers that fire on the same event - in particular when the default event still fires additionally to your custom onclick or whatnot - you may be causing several postbacks when it appears to be just a single postback. That can cause all kinds of unpredictable weirdness as it's not entirely clear which request ends up "winning" - and some odd errors may cause a session to terminate. Since this behaviour is very browser + network latency sensitive, it seems quite unpredictable when it occurs.
Delete the cookie on the client PC's that are playing up
ASP.NET Forms Authentication can redirect users to the login page if they do not have the credentials to access a specific page. It does this so that users who may have more than one login are given the opportunity to login with another account which may have the appropriate access. Basic question I know, but are the users using the same credentials the second time they log in?
Its possible that you have don't have specifically specified asp.net to use cookie based session but are allowing either cookie or cookieless sessions.
In the later case the session id is embedded in the Url. The type of issues you are experiences might be explained by that. Basically depending on how you define your links, some of them would not get the session id, so the user would get a new session when using those links - or maybe during a redirect. That could explain why at specific parts of your site the users loose their session.
If you have the mixed mode enabled, try setting it to only cookieless and go through your site.
Update: Based on the extra info posted there is surely more info needed for it. Some extra things to check:
Are you using subdomains, if that's the case the cookie might not be configured to allow that and that doesn't fail in all environments.
If you are using in-process session, make sure there isn't a bug in the application causing it to restart the process
Maybe what's causing it to ask for login again is an authorization check, and you have an issue on some roles related code
Is it possible that the user is just opening a separate window? ;)
To rule out the possibility of the browser or a browser addon messing things up, have you checked their User Agent strings? If they are randomly distributed it might not cause the problem, but if they're all the same, this might be a hint too.
I have a Drupal site with user logins. Embedded within this site is a Flash application that shows some data to everybody but allows extra functionality if the user is logged on. From within Flash, I'm using XMLRPC to access the system.check method (to determine whether the user is logged in) and the user.login method (to log in a user from within Flash).
Within Flash, everything works fine. However the Flash login state does not seem to correspond to the rest of the site. For example, if I invoke user.login via XMLRPC, subsequent calls to system.check show that I am logged in, but the Drupal user page still says I'm logged out. Or if I am logged in both places and then I log out via the Drupal user page, the next call to system.check still indicates that I am logged in.
How can I make the login state consistent between the Drupal GUI and my embedded Flash app?
(Note: I am not using any XMLRPC library, I am just constructing the requisite XML manually and sending POST methods using a URLRequest object.)
EDIT: I have confirmed via this question and also via testing with a Web Proxy that the SESS cookie returned by the user login page is being picked up and sent back by the flash application.
EDIT: And now I have shown experimentally that even though Flash (via Safari) is sending the same cookie, it gets back a DIFFERENT cookie when it connects to the XMLRPC service than when it requests and HTML page. In other words, Drupal just doesn't support this kind of synchronization and I'm stuck. I'm accepting the answer below that put me on the right track.
EDIT: AMHPHP is not fully released for Drupal6 as of this writing, but it turned out to be installed on the site anyway. Using the DrupalSite library, I was very easily able to log into and out of the site from flash, and the login remained consistent between flash and HTML.
I'm not terribly familar with Flash, but do the URLRequest objects "inherit" state from the browser session, including the user login cookies? If not, you'll need to explicitly send the login cookie with your hand-built request or Drupal will think that it's just coming from another web browser at the same IP address.
If you're not quite sure, using the Firebug plugin might be useful. It lets you inspect any requests that are being piped through the browser, examine their headers, and look at the raw HTTP response object that comes back.
Update: Even more important than the flash widget getting a session cookie is the flash widget getting the SAME session cookie as the web browser itself. Drupal allows users to log in from multiple machines simultaneously, so if the browser is creating one session and the flash widget is creating another, you'd see the behavior you're describing...
It can't be done.
(For details, please see my final edit to the original question and the equivalent information in my comment to #Eaton.)