Our Sitecore 6.6.0 (rev. 120918) based website can work over http as well as https. We also have a security requirement of making all the cookies to transfer over SSL regardless of whether the website is accessed via http.
We have achieved this requirement by using the requireSSL property in the web.config as described here: How can I set the Secure flag on an ASP.NET Session Cookie?
With this change, our public website works fine and when analyzed in Firebug, we can see that all cookies are "secure" even when the website is accessed via http.
But the problem is when I try to login to the sitecore admin portal via http, it throws the error The application is configured to issue secure cookies. These cookies require the browser to issue the request over SSL (https protocol). However, the current request is not over SSL. The only way I can access the sitecore admin portal is via https. Even with https, it gives some weird issues. After some time of use, it says that lot of admin users are logged in and I have to kick some out to get in. I also can't access the admin portal remotely.
Why is it that the public website works with SSL cookies, but the sitecore admin portal has issues with SSL cookies. Could it be and incompatible configuration in our site?
I think the problem will be that you have set <httpCookies requireSSL="true" /> which will set the cookies to secure, but also have to set the forms authentication:
<system.web>
<forms requireSSL="true">
/* forms content */
</forms>
</system.web>
As this would override the cookie setting. The problem is having that set on the forms section requires that the login happen over https not http. On your public website, you will only see this issue if there is a login form.
To fix this you will either have to enable SSL for your authoring system (which is recommended anyway) or put up with not using secure cookies.
MSDN: FormsAuthentication.RequireSSL Property
Based on the error message I'd guess the login is trying to set a cookie with the secure attribute when the connection isn't secure. This would of course succeed if the request was secure already.
As a workaround you may be able to use IIS Rewrite to redirect the request to /sitecore onto SSL prior to any cookies being set since I assume you do want all requests on SSL for content management.
I might also be totally incorrect here :)
Related
Inherited a site with a convoluted setup.
wp-login.php is served by a different subdomain than the page being password protected. It is also behind https while the password protected page is not.
When the correct password is supplied the form action goes to https://backend.sitename.com/wp-login.php?action=postpass and is redirected back to http://frontend.sitename.com/pagename/ with the password form presented again.
The developer console throws up a few warnings about cookies without a SameSite attribute set.
Not sure on the best way to correct this?
The SameSite warnings should only affect cross-site cookies. backend.sitename.com and frontend.sitename.com would be considered different subdomains, but still the same site, so that shouldn't be breaking anything.
However, I would suggest looking at a SameSite=Strict setting for that cookie. Additionally, migrating to HTTPS is a priority as those HTTP pages can easily have their cookies sniffed and stolen on an open wifi network.
You can find more context on the SameSite attribute and the upcoming change at https://web.dev/samesite-cookies-explained
I have a very strange behaviour on my production server that only happens a few times during a week. On a form login POST a redirect is sent to what looks like a cookieless URL like:
"/(F(kD5qGnK-0b5L80VYgScenFuCnjQsLR67HhXq-BWXS1hL45hhqL8AiLlEyB-9CuJgutiyXzN42w8Bo_cm2o73GFWP_fuQ1AtPfXSaB7odZYAOBnuNW3Yy873fQDpRzYgOVo3Ee48gaCbS7FUIyOBA3CksCTZ3N6YCZ7pcZylZEo01))/SiteSpecificPath/CMS/edit/"
What normally happens is a redirect to just "/SiteSpecificPath/CMS/edit/".
This in turn leads to a redirect loop going back to the login.aspx page and continuing like that.
I don't want to use cookieless so the question is how this is triggered? And is there a way to disable this behaviour? I have looked through all levels of config files and cookieless is set to false on all places.
The site is an EPiServer CMS site, but in this case it seems to be related to a normal asp.net forms login procedure that for some reason triggers a switch to cookieless URLs.
I have found some references about cookieless triggering a redirect loop, but in my case the strange thing is why it even starts using cookieless URLs in the first place.
I have also done debugging using advanced logging to see all headers sent from the browser, but I don't see anything strange there. Cookies are sent as normal, including the ASP.NET session cookie.
EDIT: This is not an access problem. A given user can normally login, but sometimes this redirect loop is entered.
Some details: IIS7 on Windows Server 2008 R2, EPiServer 6 R2, ASP.NET 4
Possibly the user doesn't has access to the redirect URL and this is why it redirects everytime to login page and continues like that.
Firstly check if the user is authorized to access the page in the redirect url.If the user isn't authorized, redirect to a page that the user can access Or update the access rights for the user.
I don't want to use cookieless so the question is how this is triggered
When using FormsAuthentication, Check your Settings for same in web.config. As seen below this has a property cookieless which can have options as AutoDetect,
UseCookies, UseUri, and UseDeviceProfile.
<authentication mode="Forms">
<!-- Detailed configuration options -->
<forms name="MyForm"
loginUrl="Login.aspx"
timeout="30"
cookieless="UseCookies"
... />
</authentication>
So, in your case the value for cookieless seems to be either : UseUri OR AutoDetect, although UseDeviceProfile is possible too.
UseUri:If this configuration option is selected, cookies will not be used for
authentication. Instead, the runtime encodes the forms authentication ticket
into the request URL
AutoDetect:Results in the use of cookies if the client browser supports cookies. Otherwise, URL encoding of the ticket will be used.
UseDeviceProfile :: Results in the use of cookies or URL encoding based on a device profile configuration stored on the web server. These profiles are stored in .browser files in the c:[WinDir]\Microsoft.NET\Framework[Version]\CONFIG\Browsers directory.
Since you don't want to use cookieless, set the value for cookieless to UseCookies.
NOTE: When using the setting cookieless="UseCookies" , requires the client browser to support cookies. If the browser does not support
cookies, forms authentication will simply not work. As
it will never receive a valid authentication cookie from the browser, ASP.NET
redirects back to the login page over and over again, and you end up in an
endless loop of presented login pages
I have an HTML5/JS website on on domain, which uses an asp.mvc web service for CORS queries on another domain.
Everything works fine with HTTP -> HTTP however as we are now adding login and authentication mechanisms for user specific content we are wanting to enable HTTPS. However it just refuses to send the options request to the web service, just gives an "Aborted" status.
I am testing using Firefox and the web service is hosted on IIS7 with a self cert (generated with SelfSSL7).
Is there any known issues around this? I did check:
Cross domain request from HTTP to HTTPS aborts immediately
However it mentions the solution is to make sure the cert is trusted, and to my knowledge SelfSSL is doing this using the /T option when I call it. So is there anything else which needs to be changed to get this working?
You will unfortunately need to manually set this in firefox, although I believe you can override this behaviour if you manually set the profile configuration.
We have a non-SSL ASP.NET web app that allows a user to login (ASP forms authentication, inproc).
Once authenticated, we redirect their browser to an external, SSL secured page on another web site / domain altogether that we do not control.
The client is redirected back to a pre-configured url on our original http web app when done.
However, the customer is then asked to "re-login" again on our side which is undesired...
It seems the forms authentication cookie is destroyed when transitioning between HTTP and HTTPS and back again.
How can I keep the forms authentication cookie alive so that the customer does not have to re-authenticate on the round trip?
It's not being destroyed; you're not authenticating on your domain, so the cookie's not being set on your domain, and thus requests on your domain will not contain said authentication cookie.
This is GOOD. If this didn't happen, then every cookie from every domain you ever visited would get sent with every request. Which is obviously 1) crazy and 2) a security hole. Setting a cookie on mydomain.com should never be visible to pages on myotherdomain.com.
If you're using a 3rd party authentication system, like google, facebook, etc, they'll all have some sort of callback token that you'll have to process and set your own cookies.
Consider to set cookie's domain property for your cookies with more specified can be found here or try this code:
Response.Cookies["your_cookie_name"].Domain = "yourdomain.com";
You're looking for a Single Sign On solution.
It might be a little overkill for your problem, for which you might just want to get the same domainname. But if that isn't an option you might want to take a look at:
Windows Identity Foundation
I have a virtual folder containing an administration application, like
https://www.mysite.com/alpha
which requires SSL. In the IIS manager properties for the folder, under "Authentication and access control", Anonymous Access is disabled and "Authenticated Access" is set to "Integrated Windows authentication."
When I connect to the site in Chrome, I receive two login boxes. The first is from mysite.com/alpha:443, and the second is from mysite.com/alpha:80. Firefox appears to re-send my credentials for the second box so it is never shown.
Any ideas why I'd be required to log in twice?
If you require SSL for authenticated users on your website (for any reason), then the best solution is to always have your "Login" page on https://. That way when they log in, they are instantly secure. The reason for this is because of the native design of SSL. It separates/secures it's self from the non secure version by not passing authentication states between http and https.
you will also have to write some logic to redirect returning authenticated visitors to the secure page (IE: visitors who can return authenticated from a cookie).
EDIT:
Since your using windows authentication, it's probably easiest to simply redirect ALL incoming http traffic to https. This means your entire site will be over SSL and will be inaccessible via http (other than to redirect to https)
I wrote a Blog Post on forcing a website to use WWW in the web address, but it can also be ported to forcing https.
Yep,
The one uses SSL, the other not.
therefore, you are not allowed to share the credential cache from a Secure session, with the one of the unsecure session.
if you require SSL, then directly redirect the users to the SSL website.