There is no code for this example as of yet because I'm after a conceptual answer.
Say I have an MVC application hosted at mydomain.com. I have a set of admin tools that are available at mydomain.com/admin. There is an attribute on the admin controller that looks for a session variable indicating whether the user is logged in or not. If not it redirects to a login page, sets the session variable and all is good. I'm fine with this .. I understand how it works.
Now say that I have another 'sub-application' at mydomain/blog. This is a separate virtual directory that has a similar security mechanism that locks down mydomain/blog/admin.
If a user is logged into /mydomain/admin (ie the session variable is set) can I then redirect them to /blog/admin/index in such a way that the session variable is passed through to this separate application. My assumption is that the session variables for the two virtual directories are distinct.
The essence of this is a way to add modular tools to a web application. If a module is installed, I want to place a link or menu that will take them to the specific module's tool-set without having to authenticate again.
One caveat, this would more than likely have to work with shared hosting scenarios where I may not have access to IIS configuration. In the scenario where I do have IIS access I would obviously have other options that I understand, but I specifically need this to work without that level of control or access.
I hope that makes sense. Please ask for any clarification.
Thanks. Simon.
Related
We're trying to setup IIS so that is uses its IIS AppPool identity when going against ACL permission checks (when getting static files from the filesystem) so that we don't have to add "everyone" or "authenticated" users to the main app folder or specific folders.
We've found that setting authenticatedUserOverride to UserWorkerProcessUser achieves the above, but no longer lets us access the specific windows user hitting the website from within the MVC application.
Is there a better way to accomplish this? Again, we're trying avoid having the specific user's credentials validated against ACLs when accessing files.
You can still get the authenticated user that is accessing the site using the LOGON_USER in the Request:
Request["LOGON_USER"]
Scott Forsyth details this on his blog under option #4 (http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk).
As for the best way to accomplish this, I think you are on the right path. I have used this approach along with the roles authorization aspect of ASP.NET to allow/deny access based on membership.
I have deployed three mvc pages to my server as virtual directories using IIS (which there are plenty of tutorials for). I need one of the apps to run when the base URL is requested. So, for example, I have a Help app which can currently be accessed via help.contoso.com/help but I want that app to run when a user simply goes to help.contoso.com instead. I gather there is some sort of redirect option but can't find an example for this type of request anywhere (they're all way more complicated and don't address my simple need). I also think there should be a way to just host the app as the 'root' web 'page' but can't find anything around that either...
I've asked similar question here because I thought the problem was in my custom membership provider.
Then I tried this:
I created two NEW asp.net MVC applications. In first one, I registered as new user using default membership provider. I closed this application, opened second one and ran it. In this application I was also logged in as user I created in first application. Logging in as user from other application doesn't work, but caching is remembered on this site. Why is it so? Is it a bug?
I think this can be expected behaviour:
If you open localhost/app1 and localhost/app2 you are on the same domain. So its valid that the same cookie is sent. I am not shure if localhost:5050 localhost:5060 are considered as the same domain. But I guess thats the case.
If the same cookie is sent the Memebershipsystem will evaluate this as the same user. Thats expected behaviour.
If you want to have these 2 webs use different pools of users you have to create a new application in the Mebershipsystem and configure it in web.config.
This will not affect the behaviour of a production system, because the 2 web will be on a different domain. each domain is only allowed to access its own cookies.
I am developing an ASP.NET MVC app with custom membership and role providers.
My custom role provider uses LinqToEntities to query the user/role mapping table and retrieve if a user is in a role or not.
When running on debug, local machine, everything is fine. When deploying on IIS7 however, I have this strange behavior:
When I change roles to a user, and then login with that user, it retains the old roles, instead of the new ones. It's like they are cached somewhere, but I already set the cacheRolesInCookie="false" option in the Web.config
Reading on the web, I saw that the option I mentioned is just a directive for the provider, meaning if I don't implement its usage, it will be ignored, is that right?
This leaves me puzzled. My provider should perform a fresh query every time a method is called. It works locally, but not on the deploy machine with IIS7.
Anyone knows if there's any hidden setting in IIS7 to make things work right?
Thanks.
After a long time I found the solution.
The problem was residing on the EF context I was using to read the users/roles.
I fixed it resintantiating the context every time a role is checked, instead of keeping the same context until application restarted.
I'm building a .Net MVC app, where I'm using one particular view to generate an internal report. I don't want the users of the site to gain access to this page at all.
I've a console app that fires every so often which will scrape some of the details from this page by hitting it's URL.
I don't like the idea of having the URL hanging out there but I'm not sure of another way to go about it.
Thoughts on what might be the best practice way for tackling this?
Edit:
Here's what I ended up doing, created a new WCF Service project in the solution. I also copied basically what was the MVC view page into a new standard web forms page in this project. On top of adding security via the regular .net Authentication methods (eg set only valid windows users can access the page), I can also lock down the vhost to only be accessed by certain IP's.
The best practice would be to expose a wcf service for this, and set up a security model that is different than website.
If you must use MVC the best approach use forms authentication with mvc and set
[Authorize(Roles = "SecureUser")]
On the View.
If the view never needs to be rendered at all except to provide data for the console app, then why not have the console app simply connect to your database to get the data directly instead of going through the web app? You could still do this for the console app even if the view does need to be available for some users, then control access to the view using the Authorization attribute, which could suitably restricted now that an external app need not have access to it.