I am looking for a website that requires HTTP authentication, so I can observe the behaviour of typical HTTP authentication dialog boxes. The reason I am looking into this, is that for some reason, on Firefox 3, our Flex app seems to open another HTTP authentication dialog box again, after cancel is clicked. It only seems to happen in Firefox 3. I want to find out if this is just a Firefox 3 issue, the nature of HTTP authentication, or something is wrong with our Flex app.
EDIT: I should clarify some more details. The problem with our flex app, is that when the authentication dialog box appears, the user clicks cancel. Then attempts to enter the page again, causing the authentication dialog box to appear again. However, if they type the correct password, the same dialog will reappear.
Thanks,
Jason
This website offers an example of HTTP authentication: http://www.httpwatch.com/httpgallery/authentication/
Firefox doesn't seem to realize that when you enter a username and password for a site it should attempt that authentication on all subsequent frames before asking you to log in again.
I'm not sure why this is, it seems like a bug to me but perhaps there is good reason for it.
One way to get around it is to begin your site on a page without frames, once HTTP authentication is finished redirect them to the framed page.
Related
When developing endpoints I need to follow a rather complex/cumbersome login process to authenticate with our gatekeeper.
For this I open the developer login page in Paw. It opens inside paw and renders the content properly. If I then click the button to actually login and an external browser is opened causing Paw to loose track of the proper cookies.
I wonder if it would be possible to keep the request inside Paws embedded browser so the cookies are not lost and I can continue testing my endpoints.
To be able to login using cookie-based auth, in Paw 2.1, you can use this hack: go to your web browser with developer mode enabled and login on the website. Then, in the Inspector / Debugger, go to Cookies (in Chrome/Safari: inspector is Cmd+Option+I, then tab "Resources" then "Cookies"). Copy the session/login cookie. Go back to Paw and add a "Cookie: mySessionCookie=value" header. It should do the trick.
Note: that's a hacky method. As mentioned in my earlier comment, a nicer way is to come.
I am trying to obtain token for my UCWA app using passive auth. My setup is that once I receive the 401 challenge, I take the link to the token service from ms_rtc_passiveauthuri parameter and I visit this website (PassiveAuth.aspx) by creating a hidden iframe in the background of my website. Couple of redirects happen in that iframe but eventually I successfuly get the cookie and I proceed with creating the UCWA app.
This works nicely in IE, Chrome, Firefox and Opera, but Safari seems to refuse to do this redirections inside of that iframe.
I also tried to visit this token service by using the XFrame (and using helper library's Transport.clientRequest), but the result is 406 Not Acceptable.
Do you know about any workaround for Safari? Or, more importantly, is my approach correct - is this how it's meant to be used?
Thanks for any suggestion
Did you manage to work this out? I am having the same issues.
Edit : See the comments below for the answer - look out for the WWW-Authenticate and Www-Authenticate headers.
I am doing an asp.net project.
In this i blocked user log in, meant's if a user logged in one system or browser he can't log in in other browser or system.
Now the problem is i want to free resources if the user directly closing the browser of shutdown the system.
Your description is somewhat vague on 'how you block the user'. Nevertheless:
Http is a stateless protocoll and you are not able to tell if a browser window is open or not.
You can manipulate this behaviour be setting the session timeout lower. You can set a session cookie, which expires at the end of the session.
Alternativly there is a javascript snippet here, that imitates this behaviour. Scroll down a little bit to get the snippet.
How to disable or block that Security Alert so that when any user access my Secured Page he
will not get Security Alert Dialog. Any help will be appreciated and thank
you in advance.
Thanks
Narendra Singh
To my knowledge, the security of a page is recognized at the browser level, and it is the browser that raises the security alert. Is it true that you are doing a redirect in your .NET code from an https page to an http page? If so, the cause is that the browser has detected a transfer from a secure page to an unsecured page without the user's consent, which causes a warning.
I'm unsure of your situation, but one way to get around this is to have the user click an html link that goes to an http page. The reason this will work, is that the browser recognizes this as the user's choice, and not a behind the scenes redirect.
I have an ASP.Net application where I am using Windows authentication to deny access to some components via roles. When using IE, the site pops up the "Authentication Required" box once, allows the user to enter their username/password for Active Directory, and all is fine.
HOWEVER, when using Firefox, it's "Authentication Required" box pops up, but when you click 'ok', it comes up again! It stays up a few dozen times! If you click cancel to all of them, it fails properly, denying access to the site. If you click cancel to all but 1 (Which you authenticate properly), it acts like you were properly authenticated.
My goal here is to have Firefox act like IE, and only ask the user once.
This forum post recommends updating your web.config to allow anon on WebResource.axd: http://forums.asp.net/p/1295804/2515478.aspx#2515478
Not ideal - I don't really understand WHY axd requests are behaving like this.
NOTE: NTLM requires keep-alive, if you install fiddler or firebug you should be able to see the "Connection: keep-alive" messages in the request header: http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication
you could get Firefox to behave exacylt like IE by adding the site to
about:config >>
network.automatic-ntlm-auth.trusted-uris
then firefox will use Windows Auth for the site
Maybe it would be best to redesign your login/authentication system such that authentication is asked only when the user first views/logs-in to the website (i.e. a login.aspx page) so that after that the users's credentials are cached throughout your website.