Umbraco - use HTTPS for some pages - ssl

I'm building a site with Umbraco, and there are a couple of pages that need to be visited over HTTPS instead of HTTP (e.g. a login page).
I've seen a couple of macros that get put on the page that needs to use HTTPS, and essentially just check the protocol used and do a Response.Redirect with the correct protocol if necessary. This seems like a terrible way of achieving what seems to be a fairly basic requirement - ideally I'd want Umbraco to render any links to these pages as <a href="https://...", not do a redirect when the user goes to a page.
With these redirecting macros, there's also the possibility of a browser displaying a warning if the user's on an HTTPS page and navigates to a HTTP one. If the links are relative, the user will be redirected from HTTPS to HTTP, and the browser may warn about this.
Is there a way to achieve this without modifying any Umbraco framework code?


There's currently no built-in way to make a few pages in Umbraco return a https url.
The only way I can think of doing this at the moment is just by making sure that you set up your links correctly.
But there's no way of stopping people from entering the insecure link. That is where the redirects come in handy though, it will make sure you don't get to a secure page insecurely.
I would recommend running the whole site in https mode. In the past, performance would have been an objection to running your full site in https mode. However with modern servers, this really shouldn't be a problem any more.

Related

What htaccess rule would you use to redirect users already using the secure version of your site to purely secure links without affecting HTTP access?

Basically if somebody is already on an HTTPS page, I don't want them to be capable of being redirected to/accidentally clicking an HTTP one (on the same site at least). It seems to me like you would use the referer as a RewriteCond to accomplish this, except for the fact that it is apparently browser policy not to send referers when going from HTTPS pages to HTTP ones. So if a user loads an HTTP page, how can I detect if they came from an HTTPS one and make sure they are redirected to the secure version of the page they are trying to access?
Unfortunately the software we are using has many hardcoded HTTP links so it is necessary to use some sort of redirection.

Asp.net MVC + subdomain areas. How to handle HTTP HEAD request?

We have a website that is used to showcase our various products. The website uses MVC4 and subdomains areas.
product1.website.com
product2.website.com
We use the subdomain to determine which area to route the request.
Lately we have been getting http HEAD requests to our site using the IP only. Without the subdomain we can't know which area to send the request.
What should we do?
Send back a 404
Redirect to our most important area/product
Redirect to our company website

why not redirect users to an overview page where they see a short list of the products. In this way you can redirect them behind the screens to whereever you want without hem knowing and this also has the ability to be used when user make typo in the url so that they are 'guided' to the right product and even find other ones.
-a 404 usually makes people seek elsewhere since tey think they have the wrong IP
- redirect to most important product may result in confusion when you change your major product (users tend to bookmark a lot of useless urls)
- redirect to the company website is to my opinion the lesser of all evils, but users tend to get lost when redirected to a 'general' website.
example: you're looking for Windows 8 download and have the IP bookmarked
- 404 error: oh the page no longer exists
- main product: windows 9 is out but for some reason you still need windows 8: you spend more time looking for what you really need and probably find it elsewhere
- overview page: you see what you need in a list and if the list is short you quickly find it, otherwise a simple search reveals the item also.
so redirect to overview page is still a winning shot in my opinion

Moving website from HTTP to fully HTTPS and SEO implications

Alright, you think that this might be one of the most asked question on the internet, and you're tired reading the exact same answers. So let's focus on one of the most common answer, and forget about the others.
One of the common answer is:
"The https-site and the http-site are two completely different sites;
it’s a little bit like having a www version of the site and a non-www
version. Make sure you have 301 redirects from the http URLs to the
https ones." (source:
http://www.seomoz.org/ugc/seo-for-https-with-s-like-secure)
So here's my question:
Why are people saying that https and http are two different websites? How different is https://www.mydomain.com from http://www.mydomain.com?
The URI is the same and the content is the same. Only the protocol changes.
Why would the protocol have any impact on SEO? Whether or not the content is encrypted from point A to point B, why would that matter SEO wise?
Thanks for your help!
-H

Http and https could technically be two different sites. You could configure your server to server completely different content. They have two different urls (the difference being that s).
That being said, almost all webmasters with both http and https serve nearly identical content whether the site is secure or not. Google recognizes this and allows you to run both at the same time without having to fear duplicate content penalties.
If you are moving from one one to another, you should treat it similarly to other url changes.
Put 301 redirects in place so that each page gets properly redirected to the same content at its new url
Register both versions in Google Webmaster Tools
I have not personally done this switch, but it should be doable without problems. I have made other types of sitewide url changes without problems in the last couple years.
The other alternative would be to run both http and https at the same time and switch users over more gradually. As they log in, for example.

Update to above answer as on August 2014, Google has just confirmed that sites secured by SSL will start getting a ranking boost. Check official statement here: http://googlewebmastercentral.blogspot.in/2014/08/https-as-ranking-signal.html

Don't think about it in terms of protocol. Think about it in terms of potentiality from a search engines point of view.
http://example.com and http://www.example.com can be completely different sites.
http://example.com/ and http://www.example.com/home can be completely different pages.
https://www.example.com and http://www.example.com can, again, be completely different sites.
In addition to this, https pages have a very hard time ranking. google etc.
If your entire site is https and pops an SSL certificate to an HTTP request, G views them as secure and that they're https for a reason. It's sometimes not very clever in this regard. If you have secure product or category pages, for instance, they simply will not rank compared to competitors. I have seen this time and again.

In recent months, it is becoming very clear Google will gently force webmasters to move to HTTPS.
Why are people saying that https and http are two different websites?
How different is www.mydomain.com from
www.mydomain.com?
Answer: Use the site: operator to find duplicate content. Go to a browser and type:
site:http://example-domain.com
and
site:https://example-domain.com
If you see both versions indexed in Google or other search engines they are duplicates. You must redirect the HTTP version to the HTTPS version to avoid diluting your websites authority and a possible penalty from Google's Panda algorithm.
Why would the protocol have any impact on SEO?
Answer:
For ecommerce websites, Google will not rank them well without being
secure. They do not want users to get their bank info etc stolen.
Google will be giving ranking boosts to sites that move to HTTPS in
the future. Although it is not a large ranking signal now, it could
become larger.
The guys at Google Chrome have submitted a proposal to dish out
warnings to users for ALL websites not using HTTPS. Yes, I know it
sounds crazy, but check
this out.
Info taken from this guide on how to move to HTTPS without killing your rank.

Recently, if SSL is inactive in Firefox browser, it shows an error. You must enable SSL and redirect the URL to HTTPS 301

Apply HTTP to one area of HTTPS website running on Apache

I run a secure website on Apache, but one part requires YouTube videos that aren't showing due to the SSL blocking them.
I therefore need to use HTTP for this part of the site (/videos). If I delete the 's' off https, it jumps back in there so can't simply change the link to it.
Is there a mod_rewrite code or something similar that might add an exception to this directory?

Switching from HTTPS to HTTP will always cause problems, especially if your users are authenticated and if you want to maintain security.
You could use YouTube via HTTPS instead, as described on the YouTube API Blog.

Mixing secure and non-secure pages

I am using the Drupal Secure Pages module to secure sensitive pages (such as login and admin pages). I am running into two issues with this:
I am able to login securely on the login page using https. However when I traverse to a non-secure page such as the home page, the browser completely forgets that I am logged in (instead of my username, the login link shows up). (The problem goes away as soon as I disable the Secure Pages module.)
Since the secure pages are getting their images using non-secure URLs, the browsers are showing warning messages. For example, "The site uses SSL, but Google Chrome has detected insecure content on the page."
Is there any clean solution to these issues?
The recommendation here was to make the entire site secure, which seems like an overkill for my site (essentially an open source community). Having said that, how much of a performance hit does something like this incur, roughly?
Thanks.

I was able to solve the issue with non-secure pages not remembering the login state. The solution was to add this line to sites/default/settings.php: $conf['https'] = TRUE; You can see the details here.
As far as I can tell, issue #2 was a browser caching issue. I cleared all the caches and cookies and the problem seems to have gone away!