Moving a Drupal site from plain HTTP to HTTPS - Issues? - drupal

I'm planning to move a site from plain HTTP to HTTPS. Should I make any adjustments to the settings or my modules?

Good question. There are few thing you need to keep in mind
Make sure they are no absolute URLs in your node text etc. because in that case the path would remain http://yoursitename.com/some/path instead of https://yoursitename/some/path . with relative URLs the paths should get changed automatically to the correct URL with https
Make sure that your server does not concurrently continue to serve pages over http for your website if you don't want that to happen. You will have to disable that directory in your apache configuration
You might want to continue serving images for instance as http instead https (or maybe you want that to be https also). Also you might want to have some redirects happening to users accessing the site using the http protocol. If you're using secure pages module then you can configure some of these issues (and more!) http://drupal.org/project/securepages

Related

Redirect & mask URL to Azure subdomain

I have an ASP.NET MVC web app running on Azure as generic-site.co. It's a white-label site that supports a number of subdomains: acme.generic-site.co, globex.generic-site.co, initech.generic-site.co, etc. Browsing to each of them changes branding on the pages, but the underlying functionality is exactly the same.
Meanwhile I have an external domain name acme-site.com hosted by GoDaddy. I want to redirect this specifically to the acme.generic-site.co subdomain, but I also want to maintain acme-site.com as the root URL for any further browsing on that site, allowing users to have a pure acme experience without any indication of the underlying generic-site-ness.
I've tried to do this using GoDaddy's Domain Forwarding with masking, but I ran into CSRF issues almost immediately.
Is there any way I can achieve this? I suspect IIS URL rewriting might be helpful, but I'm at a loss as to how to proceed.
Don't use Domain Forwarding with masking.
Just add custom domain acme-site.com to Azure Web App.
And you may need to do one of the following:
Add a middleware or something that change Host in HTTP request header from
acme.generic-site.co to acme-site.com.
Adjust the application to
load correct branding when using domain acme-site.com.
It is probably easier to use IIS Url Rewrite module as you mentioned in your question. There are several examples on how to do this. Please start with this post by Scott Forsyth: https://weblogs.asp.net/owscott/iis-url-rewrite-redirect-multiple-domain-names-to-one

Web.config redirect outside traffic for testing purposes

This is a bit of a tricky question.
I am developing a .net website, and it is hosted on our own servers.
I want to redirect outside traffic to a blank "coming soon" page, while our internal network can see the content.
How do I modify the web.config to do that?
I have already tried default document settings, but it doesn't seem to accept those, and instead displays the .NET website.
Please have a look at http://www.iis.net/learn/extensions/url-rewrite-module/creating-rewrite-rules-for-the-url-rewrite-module. It shows how to use IIS URL Rewrite Module (which in turns writes to web.config) to handle your scenario.

How to switch off Akamai caching for dynamic html files?

I run wordpress site and am using Akamai for caching. I have a link on every page so the user can switch between desktop and mobile site at any point. This link once clicked stores cookie which is passed to server with every request and so server knows if needs to return mobile site or desktop version.
Now when I access via "origin" it all works fine as it skips Akamai caching. However when accessing site as normal, so with Akamai caching, the link doesn't do anything. I'm assuming its because as far as Akamai is concerned its exactly the same url request and as Akamai has already its cached version it returns the same page ignoring the cookie all together.
Is there any way to tell akamai directly from my php files in wordpress not to cache html and do it only for images,css etc?
Or maybe is there a setting in Akamai itself where this can be specified?
If not then what other options would I have to get this working?
Yes there are a number of ways to do this. The easiest way would be to do a no cache on specific file extensions such as .html
You can tweak the files to be or not to be cached in AKAMAI through "Configuration Attributes and Digital Properties" screen.
On "Time To Live Rules", you can define path and their caching policy.
Apart from that if you want to validate if a particular web resource id rendered from AKAMAI or not, you can use Fiddler and a particular PRAGMA header.
Refer link Validate if web resource is served from AKAMAI (CDN)?? for more details.

Images from cdn, and problems with SSL

We have some images that are served up through a cdn (non ssl). During checkout process our site switches to ssl, and now we're getting warnings because the page contains unsecure elements.
Besides getting SSL on the CDN or moving all images to the secure domain, are there any work arounds for this?
Is it possible to do some thing like 'mirror' the images or something like download them and then serve them as they're requested?
Using ASP.net mvc
Best practice is to only load secure content in SSL.
Here are your options:
Get SSL on your CDN
Host your checkout-associated images somewhere with SSL (localhost or somewhere else)
Subvert your own SSL certificate
Option 3 is done by laundering the content from your CDN to the client using your webserver as an intermediary, using AJAX and a server-side script. Unfortunately there's no way to do that without adding a lot of HTTP requests and probably a forced delay on top of that (to make sure the images are stored before the client tries to load them).
That'll hurt your page load time pretty bad, and at that point you might as well just host the images on your webserver(s) since that's where they're being stored and loaded from at the end of your chain anyway.
Basically, there's no workaround. If any, it could be a severe security breach.
The best solution is to Enable SSL on the CDN, ideally with a URL that is compatible with the site's certificate.
the other alternatives, (copying files back, setting up a proxy-script) would obviously void all the benefits of the CDN.

How can I set the default page for https requests?

We have a website which has a Virtual Directory containing the secure portion of the website.
If users come to http://www.mydomain.com, they should get directed to default.aspx of the main site, but if they go to https://www.mydomain.com, they should go to default.aspx of the virtual directory.
The default page for the main site works fine, as does the secure page if I navigate to it using the full name, however I can't figure out how to set the default page for https traffic that doesn't specify a specific page.
http://www.mydomain.com - Works
https://www.mydomain.com - Page Not Found
https://www.mydomain.com/myvirtualdirectory - Page Not Found
https://www.mydomain.com/myvirtualdirectory/default.aspx - Works
What do I need to do to make links 2 and 3 load the default page show in 4?
My website is running on IIS 6.0 in Windows Server 2003
Overall, this is an anti-pattern as you state the entire behavior of the site changes based on the port. I am not stating definitively you are doing this, but consider the following:
If you are redirecting due to a user needing to see other things, you can make conditional controls that display only when in HTTPS. The same can be done for authenticated and authorized versus not.
If you are redirecting because an HTTP user needs to log in, the more consistent pattern is to have them click a log in button. And, you can force HTTPS at this point without breaking the pattern.
If you really need to redirect for some reason, there are a couple of ways of handling this:
In IIS
HTTP Handlers
URL Rewrite - requires the URL Rewrite bits for IIS 7
I imagine there are some other ways to solve this.
I finally figured out my issue. In my case, it turns out the problem was an old URL Rewrite rule I wasn't aware of that was transferring all https traffic that didn't have a file name specified to index.php, which of course didn't exist.
I found this out by viewing the IIS error logs, which was telling me the 404 was being caused by index.php

Resources