I have an MVC project using Cookie Authentication, but I want a single action to use basic authentication.
My problem is, that if the basic authentication fails, the user is redirected to the login page, specified in the cookie setup, instead of being issued a challenge.
My basic authentication code is from this page: http://www.ryadel.com/en/http-basic-authentication-asp-net-mvc-using-custom-actionfilter/
How do I prevent this redirect?
Adding the line:
filterContext.HttpContext.Request.Headers.Add("X-Requested-With", "XMLHttpRequest");
to the authentication attribute, will prevent the server from returning the login page.
Related
We'd like to support password protected pages in our CMS application. The scenario is that an administrator can set a password for a page and upon visiting the page URL, a site visitor would be prompted to enter the password in order to view the page.
The password storage / validation mechanism is not important here. What I'd like to know is the best way to handle multiple authentication cookies with the OWIN Cookie Auth middleware since we'd like the cookie to be persistent so a user does not have to re-enter the password if they refresh the page.
Options I considered:
Setting the path of the auth cookie to the individual page that has been password protected - this way it won't interfere with other password protected pages
Making the cookie name unique to the page being accessed
The issue I can see with the above approaches is that I'm not sure the above options can be configured dynamically at runtime.
Perhaps using the cookie middleware is overkill for this so I'm open to other solutions.
I'm using form authentication on Spring Security. So I go to my login form, enter my username and password, and then I have access to the protected resources on my site. Unlike basic authentication, with form authentication, the username and password is only sent on the first request.
What I don't understand is how does the Spring Security Servlet keep track of who the end user is after on subsequent requests?
I understand that with basic-authentication, the Servlet can just look up the encoded username & password in the header. But how does this work with form authentication?
I'm assuming some sort of session variable is set? If so, what is it?
Does Spring Security have some sort of temporary database linking session ids to usernames? Most importantly, if I don't use a CSRF token, would all an attacker need to do is know this session variable to impersonate the user?
Upon authentication, Spring Security adds a session attribute called SPRING_SECURITY_CONTEXT.
This session attribute is stored in server memory and is associated with your browser via the JSESSIONID cookie.
It holds an instance of SecurityContextImpl, which includes a UsernamePasswordAuthenticationToken, which holds the username.
Does Spring security have some sort of temporary database linking session ids to usernames?
Yes, in-so-far as server-side session acts like a database. On each request, the server will look up your session attributes based on the value of the JSESSIONID cookie.
If I don't use a CSRF token, would all an attacker need to do is know this session variable to impersonate the user?
Without CSRF protection, an attacker can impersonate the user by getting them to use their site and make requests (via JS or flash or what-not) to your site.
Your site is equally vulnerable to CSRF if using HTTP Basic Authentication too.
Always use CSRF protection on any important forms on your site. Why would you not?
I have web application ( built using Grails ) in which I am using Spring Security with LDAP.
Login and logout behaviour works fine in application.
Now, I wanted to build the functionality where if admin is logged in application first time forward user to specific page instead of sending user to index/home page.
I modified LoginController ( auth method ) and tried to keep track of login by new domain class. But after login Login controller "auth method" is not called.
can anyone point me to right direction ? is there other controller I need to modify ?
The default Spring Security login form POSTs to a special URL: /j_spring_security_check (the exact URL used can be changed through the apf.filterProcessesUrl configuration parameter) This POST request is handled by the Spring Security internals. To add custom login logic, you can implement your own AuthenticationSuccessHandler as described here.
I create OpenId Provider by DotNetOpenAuth Library.
I use OpenIdProviderMvc project that found on sample of DotNetOpenAuth and customized it.
Now I have 2 question:
How can I remove AskUser step?
How can i signout in provider after response to RP?
Skipping the ask user step is as easy as changing the OpenIdController.ProcessAuthRequest method so that instead of redirecting to the AskUser action, it always (effectively) follows the path as if AutoRespondIfPossible returned true.
You can effectively sign the user out "after" response to RP by clearing the cookie in the same redirect instruction to the browser. So before returning from the ProcessAuthRequest method, try:
FormsAuthentication.SignOut();
If that doesn't work, you may have to do the cookie manipulation yourself as described in this question.
Whenever cookies are disabled in my browser and then i try to login on login page it unable to create session and so unable to login in system. Then i change the cookie setting to
<sessionState cookieless="true" timeout="20" />
in my web.config and then try to login Post action of the login function it doesnt call and whenever i input username and password and sumbit it, it call simple login action instead of Post one. What is the issue?
You shouldn't confuse session with authentication. If you are using Forms Authentication a separate cookie will be used to track authenticated users. Here's a good article explaining how to enable cookieless forms authentication. You could set the cookieless attribute on the <forms> element.
Quote:
"im not using form authentication instead i have built my own login mechanism. I just want to login user whenever cookies are disabled in user browser"
End Quote
That's the problem with rolling your own login: you lose all the benefits of using Membership Providers. You should cast your "own login mechanism" into a custom membership provider so that you can benefit from what ASP.NET provides out of the box.
Writing a custom membership provider is not difficult, and there are loads of articles, samples and blogs on the subject.
4guysfromrolla.com, for example, has a series of articles dedicated to the ASP.NET membership provider.