I'm working on a website that uses a non-secured asp.net session cookie.
The session is shared between http and https.
We want to use different sessions for http and https (because of security reasons).
Is this configurable in ASP.NET, the httpCookies config element in system.web isn't specific enough. I'd rather not programatically build this.
If it's not possible, what approach should I take?
I would setup the https files in a folder called "Secure" as a sub-application of the http app in IIS. Right click on My computer (or Computer in Windows Server 2008) and click on "Manage". Expand Services, then Internet Information Service, then Websites. Then, expand your website and right click on the "Secure" folder that you just created. On the default tab, click Create Application. Anytime that you have a switch to a https page, make sure that you are using "https://www.yourdomain.com/Secure/" on the front of the url. I would just use a Configuration Setting in web.config to set that url string as a programmatically accessible value. Then, your https sub-application will set you a new session cookie as it is a separate application.
Related
I created two different asp.net MVC application using the default template, and launches the two simultaneously, when I login with site a, and refresh site b, site b tries to use the login detail of site a. How do I stop it?
I suspect you are having an issue with the AntiForgery tokens. Something I add by default to my new MVC projects is this (add to Global.asax) :
AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.NameIdentifier;
I think this SO answer provides a fairly complete overview
Authentication is persisted via cookies and cookies are domain-bound. All cookies tied to the domain will be sent to a request to that domain, regardless of how many actual websites there are in the mix. Although you haven't specified, you're most likely in development and loading the sites under different localhost ports. It's important to know that a different port is not enough to prevent cookies from being shared. In all cases, when developing locally, the domain will be localhost and cookies will be shared between all sites running on localhost.
You have a couple of options. The simplest option is to simply customize the auth cookie name for each site. If you're using ASP.NET Identity, just add the following property to your cookie auth config:
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
...
CookieName = "foo",
});
If the two sites use different auth cookies (based on the name), it won't matter if they both receive both; they'll only look at the one that belongs to them.
The second option is to use something other than localhost. For example, you can make use of something like localtest.me. It's a domain that has been helpfully set up to redirect all subdomains to localhost. That way you can test your sites via something like site1.localtest.me:12345 and site2.localtest.met:54321 (notice that the ports will be the same as they were with just localhost). However, since these are now different domains, the cookies will no longer be shared. However, doing this requires making changes to IIS Express' ApplicationHost.config file, and you could potentially mess something up if you're not careful. It also will be confined to your specific machine, so any other developers would need to make the same change on their machines. Changing the cookie name will be universally applied.
I have been using Windows Azure to host some of our internal utility projects using Web App. When I create a new web app say "MyTestApp", the default URL created in portal will be:
"http://MyTestApp.azurewebsites.net"
Refer Image
However, when I click this URL, it will not open in browser. To fix it, I have to manually append "s" in the protocol to make it
"https://MyTestApp.azurewebsites.net".
I understand that by default, Azure secures the *.azurewebsites.net wildcard domain with a single SSL certificate, so the clients can access the app at
"https://appname.azurewebsites.net"
But I wondering why the portal display the non SSL URL (http). Is there a reason for that?
Update:
I tested it with Firefox too (based on suggestion in comments) and tried both hitting URL as well as Browse button. Since the URL is http, on new tab, it just say "waiting for MyTestApp..." and then "waiting for login.microsoft.com...".
However, when I click this URL, it will not open the WebApp in browser.
If we click the URL and the [Overview] table is fully loaded, then it will work correctly . We also can browse the website via click the [Browse] option.
why the portal display the non-SSL URL (http)?
This may be the topic about advantage and disadvantage of Http VS Https. Generally, one of the primary blockers for HTTPS adoption is the fact that the HTTPS protocol is slow. Here’s a very informative ServerFault thread showing just how big of a slowdown.HTTPS encrypts traffic between us and a server. It is more security than HTTP. And Azure also allow HTTPS access to our WebApp and support to enforce HTTPS on our WebApp.
I need to find out the base URI of an ASP.NET Web API application hosted in IIS 7.5+, right after the app's startup, but before any client request may have reached it. The scenario where I need this is the following: a periodic check is performed, through a timer that runs independent of user requests and which is triggered together with the app startup (same process); if this check passes certain conditions, some registered users will receive an email containing a hyperlink to my web application. Now, I don't want to hardcode that link anywhere, but rather get it dynamically from the web application itself. It would be simple to figure it out from inside the context of a client request and then cache it in memory but, as you can imagine, the timer might go off before any request reaches the server.
How could I then determine correctly the application's base URI? I was thinking the most appropriate place would be the Global.asax.cs file, during the web app's startup, yet i couldn't find anything that looked helpful.
Given a full URL such as "http://mydomain.com/MyApplication/Controller/Action", you can get some of this information from the System.Web.Hosting.HostingEnvironment.ApplicationHost object. You can get the following:
ApplicationVirtualPath -> "/MyApplication"
SiteName => "Default Web Site"
However, you will not be able to get the domain name before an actual request comes in. This is because an IIS website can accept requests for many different domains, some of which are only known via DNS and never configured anywhere.
For example, your website could respond to both mydomain.com and www.mydomain.com. Which is the correct one that you want to put in your link?
You can configure your IIS website to only accept connections that request a particular host, but that cannot be retrieved from an ASP.NET application.
I'm working on a CMS that can run either with or without https enabled on the webserver. I'd like to be able to detect whether https is enabled or not, so that I can act accordingly (for example, display some https-related options to the administrator, and redirect to https for administrator logins).
I'm not looking for Request.IsSecureConnection because that only tells me if the current request is via https. I want something that will tell me whether the current bindings for the site in IIS include a binding for https at the same domain as the current request is on. So, for example, even if the current request is for http://example.com/ and thus not secure, I want to know whether https://example.com/ would work so I can (for example) redirect the user to it if they log in as administrator.
I've had no luck looking for anything in System.Web.Configuration that will tell me about the bindings of the current site, though.
My current workaround is just to require the administrator to set an appSetting in web.config if https is enabled, but I'd prefer if I could make it automatic. Having to set the same thing twice - once in IIS and once in web.config - is confusing.
The simplest way is to make an https request to the site from the site and if it succeeds then you know https is supported. Cache this in a static variable so it's only called once per app invocation.
Depending on your IIS version you can use managemed .net code to do administrative tasks in IIS7. This is an example of querying a site for its bindings to see if https is enabled
http://msdn.microsoft.com/en-us/library/microsoft.web.administration.bindingcollection(v=VS.90).aspx
We are launching a new web site using a sub-domain and need to ensure that users logging in to the original (main domain) site, are also authenticated in the new site.
I believe I need to ensure all related web.config settings (forms authentication, cookie names etc) are the same in both applications and also manually set the machineKey validationKey/decryptionKeys (again, the same in both apps).
My question is, if I now manually set theses keys in my main app, will it break the existing logins?
We are using the "hashed" format for passwords.
Depends what you mean by "break". If you modify the machineKeys/encryptiong keys people might have to log back in but the login functionality will continue to work as before.
You also need to make sure that the domain for your cookie are set to domain.com in both places (without the www) or the authentication cookies will not be shard correctly between the sites.