Now, I login to my web application, but with a user that does NOT have roleA. When I visit SomePage.aspx I get redirected to Login.aspx, the url specified in loginUrl of the forms element. So, my question is shouldn't I be able be specify an authorization denied message or url? If the user is authenticated, but not authorized why would I want to redirect to the login page. It's confusing as hell to the user.
I'm using the Authorize attribute to filter controller actions based on user roles, but if an unauthorized action is attempted, the user is redirected back to the login page. As I user I would find this confusing and irritating. How can I instead show an error message informing the user they need certain roles, and remain on the view where they attempted an action?
I am using ASP.NET MVC 3 and am trying to do something that should be really straight forward...
My application uses Forms authentication and that is working perfectly for controllers/actions. For example if I decorate either a controller or an action with the attribute below only members of the administrators group can view them:
[Authorize(Roles="Administrators")]
However I have a folder under the default Scripts folder called Admin. I only want members of the Administrators group to be able to access scripts within this directory so I created a new web.config in the directory with the following inside:
[code]....
However no matter whether a user is a member of the Administrators group or not they receive a 302 Found message and are then redirected to the login page.
If I change the web.config to allow user="*" then it works. It also works if I add an allow users="Username" for a specific user I am testing with.
I installed microsoft web search in my machine and now I am getting below error
- I have already uninstalled webserch -Disabled the indexing services - Deleted all files from c:/windows/microsoft.net/framework/v1.1.4322/Temporary ASP.NET Files - Restarted application and computer several times - restarted IIS many times
Nothing is working this stupid error, I have already wasted more than 3 days now can anyone help me fixing this. Configuration Error Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately. Parser Error Message: Access is denied: 'ConcordeSF'. Source Error:
[Code]....
Source File: c:windowsmicrosoft.netframeworkv1.1.4322Configmachine.config Line: 198 Assembly Load Trace: The following information can be helpful to determine why the assembly 'ConcordeSF' could not be loaded.
When a user attempts to directly visit the url admin.aspx, and they are not an admin, they are redirected to the login page. However, the user then attempts to visit ViewWeek.aspx, it indicates that they are still logged in. Why does this ASP.NET authorization boot the user to the login screen, yet keep the user logged in? I'd rather it just direct the user to the default URL specified in the forms tag.
Our team has recently implemented a role permission based authorization so that we can have granular control. This is similar to what Rockford Lhotka suggests herehttp://www.lhotka.net/weblog/PermissionbasedAuthorizationVsRolebasedAuthorization.aspx I have also read about the Claims based authorization which to me looks very similar to what we have. Can some one put in simple terms what the advantages of claims based authorization are.
Is this a security issue or by design?string UID = "randomusername" // does not exists in aspnet_Users table FormsAuthentication.RedirectFromLoginPage(UID, false);Authenticates users, redirects to login page.Profile Page is set to chech User.Identity.IsAuthenticated etc...when they update the profile, it ads the user to the aspnet_users table automatically, which is not what I want.
is it possible to set the FormsAuthentication.FormsCookieName in Codebehind(f.e. in Global.asax)? All properties that i have seen that lead to this config-parameter are readonly.
When i tried to implement form authentication in various subfolders i am getting an error as follows:it is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
I have both the wcf and asp.net project together in the same project. (I'm running on Azure, so this is more convenient).I have this set in the web.config:
<system.serviceModel> <serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> </system.serviceModel> y wcf service is decorated with: [code]...
I have a login page that is set to the loginUrl property in the authentication section of my web.config file. I am trying to reference a CSS stylesheet, but it doesn't seem to be doing anything. Here is my markup:
[Code]....
I am able to do this just fine on my other page. One thing I noticed was when I click on "View Source" and try to click the link to the stylesheet, it doesn't take me there, and instead changes the "action" property of the form element to this:
After browsing the MVC section on CodePlex I noticed that the [Authorize] attribute in MVC returns a HttpUnauthorizedResult() when authorization fails (codeplex AuthorizeAttribute class). In the source of HttpUnauthorizedResult() from CodePlex is the code (I'm not allowed to enter another URL as my rep isn't high enough, but replace the numbers on the URL above with 22929#266476):
// 401 is the HTTP status code for unauthorized access - setting this // will cause the active authentication module to execute its default // unauthorized handler context.HttpContext.Response.StatusCode = 401;
In particular, the comment describes the authentication module's default unauthorized handler. I can't seem to find any information on this default unauthorized handler. In particular, I'm not using ormsAuthentication and when authorization fails I get an ugly IIS 401 error page. Does anyone know about this default unauthorized handler, and in particular how FormsAuthentication hooks itself in to override it? I'm writing a really simple app for my football team who confirm or deny whether they can play a particular match. If I enable FormsAuthentication in the web.config the redirect works, but I'm not using FormsAuthentication and I'd like to know if there's a workaround.
Just a quick question i've been asked to look at enhancing security but encrypting passwords we store in a db table, essentially the data thats linked to the user account isnt sensitive however its more to stop someone reading passwords out of the table directly etc
I've read multiple ways of implimenting hashing etc i've started using FormsAuthentication.HashPasswordForStoringInConfigFile //create new salt and update the password Hashtable newInfo = new Hashtable(); newInfo["salt"] = GenerateFriendlyPassword(5); string tmppass = FormsAuthentication.HashPasswordForStoringInConfigFile(txtNewPass1.Text.ToString() + newInfo["salt"].ToString(), "SHA1"); newInfo["passwordHash"] = tmppass;
Generate friendly password returns a 5 char string based on a random position in a valid char array containing a - z and 0 - 9At present the functionality is at page level in the code behind, re this is the forms authentication HashPasswordForStoringInConfigFile function thread safe? Or do i need to look at implimenting this in a different wayCheers appreciate your response as im always jubious about multi threading etc,
I reach my login page with the parameter "returnUrl" set to the URL I was on. Then, I login via OpenID (DotNetOpenAuth), and call FormsAuthentication.RedirectFromLoginPage(). The login is successful, however I am not returned to the original page I was on.
I'm having the same problem on logout - when I log out I don't remain on the same page, even though the logout link contains the correct "returnUrl" parameter.
What am I doing wrong?
Here is the code snippet. I am returning EmptyResult() after the call to RedirectFromLoginPage, because I don't really know what to do (see this related question)
using (var relayingParty = new OpenIdRelyingParty()) { var response = relayingParty.GetResponse();[code]....
Is it OK to call FormsAuthentication.RedirectFromLoginPage many times?
On login page we test if user is already logged in, and if it is we just redirect him to default page with FormsAuthentication.RedirectFromLoginPage...
Question is if user sets a script that loads login page 10'000 times, would calling the FormsAuthentication.RedirectFromLoginPage that many times make problems?
I am having some trouble with active directory authentication using FormsAuthentication in ASP.NET MVC 2 (VS 2010).
As I understand it I should be able to step into/through the Microsoft source code for FormsAuthentication.Authenticate if I check 'Enable source server support' and 'Enable .Net Framework source stepping' in Options->Debug->General and specify 'Microsoft Symbol Servers' in Options->Debug->Symbols.
I have done this and can step into a whole bunch of MS source code, but not FormsAuthentication.Authenticate. The debugger simple steps over it.
If I could step into FormsAuthentication.Authenticate it would make my life a whole lot easier.
I am experiencing a strange problem with asp.net forms authentication. This problem only occurs for 3 users out of 30+ users that have successfully logged in. I am using very basic auth code that I have used many times and have never seen this problem. After the users successfully authenticates and the auth cookie is created, cookie added, and response.redirect to FormsAuthentication.GetRedirect(userid, false) is called. The Application_AuthenticateRequest method in Global.asax is hit.
// Extract the forms authentication cookie tring cookieName = FormsAuthentication.FormsCookieName; HttpCookie authCookie = Context.Request.Cookies[cookieName]; if (null == authCookie) { // There is no authentication cookie. return; }
So immediately after a "good" cookie is saved and the redirect occurs the cookie is null. I have run the code through the debugger and the cookie is only null on these 3 users. But the cookie looks the same as the cookie for the many users that login successfully.
