I'm having a strange issue with Plone content.
1) Sometimes a few pages that are externally visible cannot be accessed by non-authenticated users without Plone asking a username/password. These same pages could be accessed by anonymous users before.
2) When authenticated member just opens one of these pages in his navigator, the anonymous users can access the page again - until the same problem occurs again, normally after some days.
I have yet to understand when / which cases does this shift from "being available for anonymous" to "not available" happens. The "official state" of the content item stays always the same as "externally visible" (using the default Plone intranet workflow).
Plone version 4.2.0.1.
Even though the page itself is available to anonymous user a badly coded site might contains elements (viewlets, portlets) which trigger Unauthorized exception and redirect user to the login page. For example, a custom news listing incorrectly refers to a unpublished news item and when anonymous user tries to read data from this item an Unauthorized exception is occured.
The best way to debug this issue is to enabled logging of Unauthorized exceptions in Zope Management Interface *error_log* service and see what Python code actually causes the login page to show up.
However, vanilla Plone installation should have not this behavior. It comes to down customizations.
One possible reason for 2) is that your front-end web server or cache is badly configured and it servers cached "logged in" page for anonymous user. For debugging purposes I suggest you directly access the site over Zope port and skip all front end web servers in the debugging chain for starters.
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.
Our ASP.NET application is hosted in IIS 7.5 and has the following setup:
main site is hosted under root IIS folder accessible with http://siteurl (1)
we have a separate app in the same AppPool hosted under http://siteurl/Intranet (2)
Main app (1) has Anonymous Authentication enabled along side Forms Authentication (url: siteurl/loginform).
Second app (2) has Integrated Authentication (NTLM).
The login procedure works as following:
User goes to siteurl first
User gets redirected to /Intranet to check integrated auth
If integrated is accepted user gets redirected back with proper auth cookies to siteurl and gets access to the site
If integrated fails user gets redirected to siteurl/loginForm to manually fill in credentials
We have some issues with Internet Explorer (8, 9, 10) that refuses to submit the form data at step 4. It appears to be a known behavior that IE will not POST content to an unauthenticated site once the NTLM negotiation started for that session. I have considered some workarounds for this:
store credentials in a cookie (with JS) and on the server if the POST content has 0 length try to check the cookie values. delete the cookie afterwards
send credentials using GET instead of POST (ugly as we need to make sure the user does not see his just posted password in the browser address bar)
Provide a link to the user to open a new tab and continue the auth process in a separate browser session (this seems to work as IE will happily send POST data from a second tab)
Are there any other options we might have to get around this issue?
From the above 3 which one would be preferable and what unconsidered pitfalls we might encounter?
I wrote about this issue here: http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication-challenges-are-expected.aspx
Your question omits important information which makes it hard to troubleshoot. You should never see the problem described with the literal URLs you've used, because IE uses protection spaces to decide whether a site is going to demand credentials via a HTTP/401 and example.com/ and example.com/foo/ are different protection spaces.
It would be very helpful if you could share a Fiddler log of this scenario for better troubleshooting.
Environment:
Server 2008
IIS 7, integrated mode
.Net 4
ASP.NET WebForms Routing (which uses the same .dll as MVC routing, though I'm not sure which version)
Cookieless sessions (session ID travels around on the user's URL).
We have an application that uses routing to identify which organization a user is associated with. The URL will take the form domain/Organization/OrganizationSubCategory. The user follows their custom URL and sees a landing page. When they hit next, they are directed to a page that collects some demographic info, then they hit next to proceed to the application. When they do, the user is added (if necessary) to their organization in our database. After the initial landing page, routing no longer applies - the user is directed to regular aspx pages.
The site is receiving a fair amount of users entering the app; an average of 850 per day.
The problem is that a small number (less than 1%) of users are getting added to the wrong organization.
We are logging information on the landing page and when they submit the demographic page. One thing we log is Request.RawUrl. We started noticing users who are associated with one organization being logged as having requested the full correct URL (including the sub-category) of another organization. Sometimes nobody legitimately came in following the incorrect organization URL even in the same day. We've had people report directly that they just created the "sub category" (using an administrative application), instructed a user to follow their unique URL, and yet the logs show an entirely different URL for that very user (I know it's that user because I'm logging email address and session ID so I can associate the same user's path through the landing page and the demographic page). It's as if IIS is sometimes creating a new session, and simply assigning some previously requested URL to that user.
In an attempt to eliminate some sort of caching, we have:
Set the config httpRuntime element's enableKernelOutputCache attribute to false
Disabled caching in IIS settings
Set the config sessionState element's regenerateExpiredSessionId attribute to false (even though we haven't seen the session ids being re-used).
Other suggestions?
Are these internal users? Are there proxy considerations? That wouldn't explain a wrong url though. Are you 100% certain the users were given url A and they show up with URL b? Do you have any routing modules currently assigned? Are you sure its not getting rewritten by a rule in another module?
Could this be an application issue where their 'new user' email (for ex) contains the wrong url?
Well, we still don't know with complete confidence, but it seems that users in one organization were most likely searching the Internet to find URLs into the system and following those.
I can't explain the report we had as I described in the original post.
When I tried to enhance logging to capture pre-post session creation to prove it for sure, the logging on the begin request event worked in our QA environment (same as production), but just flat wouldn't work in production. I could never determine why.
I have an asp.net app. It has a page that requires authentication. The authenticated user can view the page because he/she is authenticated. The page makes a jQuery Ajax call to a WCF service. The WCF service checks that the user is authenticated via HttpContext. I have a user that is using WinXP and IE8. This user can authenticate to the page, but when the Ajax call is made from the page to the wb service, the user recieves my "session not authenticated" message on the page, generated by the service and displayed on the page. When I use the same OS/browser combo, the page and service work just fine, as expected; no errors.
What option in this user's IE settings would cause this behavior?
It turns out that I was just being stupid and was violating the "same origin principle". My service was at mydomain.com and my user was probably on a page at www.mydomain.com. The service would fail because the domains didn't match completely. So, I setup some re-write rules on the server so that no matter what variant of the domain that was requested by the browser, it would always re-write to www.mydomain.com. Then, I simply set the the service call to the that domain (or in this case, just used window.location.hostname), and all problems were resolved. Big "D'oh" moment.
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.)