Is there a way to implement forms authentication, but only for a specific URL. For example, I would want the formsAuthentication to protect the site on staging.mydomain.com but not hinder access to www.mydomain.com if the web.config accidentally got moved over to the production site.
This can be achieved, but you'll have to implement your own IHttpModule for it. Alas FormsAuthenticationModule is sealed, meaning that you would have to start from scratch, but Reflector can be a great help there.
we have used a simple workaround in the past.
We set the default Login page to be a simple page that is accessible to anonymous users, lets call it checkDomain.aspx
In that page, we do a quick check of the domain and based on that we redirect users to the login.aspx page in the staging site, or to the original requested url in the production site. this wasnt pretty but it was quick and easy to implement for a short period of time when we feared something like that could happen.
Forms auth is implemented on the web site instance. Its not going to work that way.
The web.config is where you can manage what FormsAuthentication does. So, the answer is kind of in your question and #Andrew is right.
However, you might be able to do something in your global.asax to recognize the server or domain that the site is running on and disable FormsAuthentication. Maybe create a user that has access to everything and manually set a FormsAuthenticationTicket to that user on session start if the domain is www.mydomain.com.
This is a bit hackish and I would suggest coming up with an out of band way to control your web.config instead.
Related
I'm working on adding a new webapp to an existing website. I've been directed to write the webapp in ASP.NET. The existing website is written in ColdFusion. For the most part, the ASP.NET webapp is completely stand-alone, but it needs to interact with the ColdFusion code in one important way - if somebody logs in to the ColdFusion site, we don't want them to have to log in again when visiting an ASP.NET page.
When someone logs in to the ColdFusion site, their username is stored in a cookie, along with a login token that can be looked up in our database. My .NET is a little rusty, so I'm having trouble visualizing how the ASP.NET code should use this data. I've already written a simple MembershipProvider that can be used to log in/out out the ASP.NET app using the data in our existing database tables, which are shared with the ColdFusion code.
What I'd like to know is - how can I make sure the ASP.NET app detects the cookies set by the ColdFusion app (I imagine they'd be sent to the ASP.NET pages, since everything is hosted on one domain), and automatically logs the user in using the MembershipProvider and Forms Authentication, using the credentials supplied in the cookie? I'm thinking that putting some kind of cookie check and log in function in the Global.asax file, set to run every page load for every page... but that seems kind of clunky. Also, do people still use the Global.asax file anyway? I had thought there was a more modern method.... Also, how can I manually log someone in using Forms Authentication and a custom membership provider? Currently my code allows the user to log in using the provided login control, but I'm not sure how to log the user in without them having to do anything.
Thanks in advance for any help. Looking over the MembershipProvider tutorials and the MSDN documentation it seems to me like the answer should be staring me in the face, but for some reason I just can't see it. Maybe not enough coffee....
Not sure if this is what you're looking for:
FormsAuthentication.SetAuthCookie("the username goes here",false);
Reference
I'm a CF developer ususally, but we had to do some integration with a .NET application recently and the way we approached it was to keep the CF and .NET sessions separate but ensure that login happened on both so when the user moved from one to the other they were still logged in.
So is there perhaps a way for you to hit your ASP.NET application with a request to login a user when you login using the CF application? Perhaps you could have an iframe on the page that you can load when the CF login is complete that holds a login service for the .NET app?
This way you would not need to worry about one app server reading the other app server's cookies, instead there would be two sets of cookies, one for ASP and one for CF.
Hope that helps!
The way I would approach it, is I would have a specific page that acts as a liaison between the CF and .NET layer. That page would implement your business layer and just check to see if the Cookie is there, if so read it in, do the lookup and login the user or whatever business logic that needs to be done. How would you accomplish the login/authentication, well that’s all based on your login/authentication code.
The only link I can offer is the basic of cookies in ASP.net
http://msdn.microsoft.com/en-us/library/aa289495(v=vs.71).aspx
Edit: found another link that might be helpful.
http://www.aspnettutorials.com/tutorials/network/cookies-csharp.aspx
I have a question that doesn't need any specific answer, just a general direction of what to do. I work for a company that has many sites. Each site requires a login at some point. We have a single Accounts database that all of the sites hit.
One of the requirements for the login system is that if we login on one site, we should automatically be logged in elsewhere.
The way it works right now is that on page load (or init, forget which) at any of our sites (let's say site1.com), it redirects to a "master" site (let's say sitemaster.com). On sitemaster.com there is a web service which checks to see if a cookie exists on sitemaster.com for that user. If it does, it redirects back and lets site1.com know that the user has already logged in (site1.com then creates a cookie for site1.com so we don't have to redirect to sitemaster.com in the future). If the user is not logged in at sitemaster.com, site1.com will then ask the user to login and, on submit, it redirects the user to sitemaster.com which logs them in, creates a cookie under sitemaster.com domain, redirects back to site1.com and lets site1.com know that the user is logged in (which then creates the cookie for site1.com).
On logout a similar method is employed.
Is this the best way of handling universal logins, or auto-logins across multiple sites? Is there a better way of doing things?
Some requirements:
Most of our sites are in .NET 2.0, but there are plans to update them all to .NET 4.0. We want the best method for this auto-login system so if something requires .NET 4.0, that's ok.
The solution should not require javascript (our current solution requires javascript during the login process).
The solution should not require Flash.
It's ok to use iframes, as long as javascript is not requred.
We would like to be able to do AJAX logins (using jQuery) without having the site refresh. The current solution, due to the redirects, prevents us from doing that. (eg: Pop up a modal box asking the user to login, and when they do, the modal box disappears and some content is changed, but no site refresh required). This isn't absolutely necessary, but at the very least we should be able to verify a login using AJAX before any redirecting takes place.
Any articles or suggestions will be very helpful. I also have some questions related to the best way of re-using the auto-login code across sites (varying from ASP.NET 2.0 Forms to ASP.NET 4.0 MVC, but I'll save that for another question).
Bara
At a simple level, your system works very much like OpenID. It might be worth implementing your own internal OpenID provider and save yourself all of the custom work and maintenance/bugfixes etc for a bespoke system. OpenID is supported by many many sites, including stackoverflow.com.
http://openid.net/
and
http://wiki.openid.net/Run-your-own-identity-server
which leads to:
http://www.dotnetopenauth.net/
-Oisin
What you've described is a federated Web Single Sign-On scheme. Ultimately, I'd recommend that rather than rolling your own, you adopted the WS-Federation standard. The advantages being that you're less susceptible to introducing security vulnerabilities and also have the ability to achieve Single Sign-On with applications other than bespoke ASP.NET apps.
I'm currently looking into url-rewriting and how it should be done right and hope you have some inputs here.
At the current stage of development only the kind of url-rewriting I'm interested in is adding facebook like behavior to businesses to which we provide services on our site, i.e. www.mysite.com/ShowBusinessInfo.aspx?id=1 should be rewritten to www.mysite.com/HostedBusinessName. - The idea is that when a business registers on our site they can choose whatever the last part of the url should be.
What would be the best way to support this feature? Custom IHttpModule, Global.asax (I'm afraid that this is too slow?), UrlRewriter.net/UrlRewriting.net or a completely different solution.
The site is developed in asp.net and runs on IIS 7.5.
I've actually done something like this before and this is the article I used as a resource: http://stweet.wordpress.com/2010/03/15/creating-a-new-website-programmatically-on-iis-using-asp-net/
This article will tell you how to programmically add a web site to your IIS using C#. Keep in mind that depending on how your IIS and DNS is setup, you may need to also modify your DNS server. You can find various scripts for doing this here: http://msdn.microsoft.com/en-us/library/ms682129%28VS.85%29.aspx
Hope this helps!
If you have fairly simply rewriting rules, I'd use an IHttpModule that attempts to match the URL's LocalPath property with a value in your DB, and then calls context.RewritePath(string).
If you have more complex stuff, then I'd start looking at UrlRewriting.NET or the routing options in ASP.NET.
Our customer has a requirement to extend the functionality of their existing large government project. It is an ASP.NET 3.5 (recently upgraded from 2.0) project.
The existing solution is quite a behemoth that is almost unmaintainable so they have decided that they want to provide the new functionality by hosting it on another website that is shown within the existing website.
As to how this is best to be done I'm not quite sure right now and if there is any security issues preventing it or that need to be considered.
Essentially the user would log on to the existing web site as normal and when cliicking on a certain link the page would load as normal with some kind of frame or control that has within it the contents of the page from the other site. IE. They do not want to simply redirect to the other site they want to show it embedded within the current one such that the existing menus etc are still available.
I believe if information needed to be passed to the embedded page it would be done using query strings as I'm not sure if there is even another way to accomplish this.
Can anyone give me some pointers on where to start at looking to implement this or any potential pitfalls I should be aware of.
Thanks
if the 2 sites are hosted from the same network (low latency between them) you could use state server for session management. that way, when you authenticate on one site, you will also be authenticated on the other, and share user state across them.
its pretty simple, in your web config of each web server you'd point to the state server (which could be located on one of the web servers)
<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="192.168.1.103:42424"
/>
</system.web>
</configuration>
http://en.csharp-online.net/ASP.NET_State_Management%E2%80%94Storing_Session_State_out_of_Process
create a virtual directory under the primary domain. If your domain is www.mydomain.com then create a virtual directory www.mydomain.com/site and port the new website application under /site virtual directory. This was linking should become very much relavant. With this the virtual-directory application will also retain all domain cookies set by primary domain.
I would suggest to make the second website look exactly like the first one or at least use the same MasterPage, so you can redirect from one site to another without any visual difference.
If your site needs authentication, consider that you would need to do something to prevent the user to log in twice, an option could be to send an encrypted token to the second site.
All of this if you are forced to have a second site, if not just use a virtual directory
You could use something like UFrame. I've used it a couple of times and seems to do quite a good job with it...
"goodness of UpdatePanel and IFRAME combined"
http://www.codeproject.com/KB/aspnet/uframe.aspx
I would use an iFrame to embed that website in within your existing application. Just set the "src" attribute and pass in any query string parameters the other site needs to render correctly.
You can still pass in sensitive data in the query string, however it would make sure to encrypt it before sending it in.
I know it is not the most elegant solution, but it gets the job done. And from the description of the existing app, it doesn't seem like your customer cares for "elegance" :)
Hope this helps
i wish to require a popup window for users to type, to access my website. For the username, password .. i was hoping to have a few hardcoded names/passwords in some file. I was told that Digest Authorisation could be used, to do this.
If i've got a stock standard ASP.NET website, where can i define the username's / password?
please note, this username/password only 'unlocks' the site .. but doesn't log them INTO the site. they will need their website username/password for that.
i hope that makes sence.
please help!
Depending on your access to the machine, a really simple option is a program called IISPassword, some providers have this installed, which allows you to use apache style .htaccess .htpassword files.
Once this is installed, setting up takes about 5 mins, just find a unix crypt function to handle the passwords, and it just works, don't have to touch aspnet at all.
Have only used this on IIS 5 and 6, but might work on 7.
Hope that helps.
I think that your users will not appreciate having to enter two passwords to use your site. I think you would be better served to stick with the web site login as the sole means to access the site and simply redirect non-logged in users to the logon page. You may also want an "about us" page that is publicly available for potential future users if your site is public.
You can find a pretty comprehensive guide to authentication in ASP.NET here. According to the article, Digest Authentication requires that you store user ids/passwords in Active Directory.