Hi Forum,

It’s very urgent for us (Calvin Frei and me) to find a solution. We never had this kind of problems with umbraco before.
We searched in the whole mssql database for https:// but we couldn’t find anything related to this behavior.

Thx a LOT
Tobias

We found one interesting thing: If you work with httpS in the umbraco backend, all published nodes have an alternate link WITH httpS://. Did anyone else experience the same behavior?

An other interesting thing: If we add one rewritings in the config/UrlRewriting.config which redirects from http:// to httpS:// for example: http://www.mydomain.ch/login to httpS://www.mydomain.ch/login and the app pool restarts and the entry "Loading content from disk cache" is listed in the umbracoLogs, all nodes changes the "Link to document" to httpS and all library.NiceUrl(id) redirects the user with httpS, but we added just one rewriting rule (login) and not for all nodes!

No hints?

We know - it sounds surreal... 

Not a clue, you might want to check if the uninstall of https redirect completed properly (open up the package zip file and figure out which files it puts in your umbraco install and make sure they're deleted).

Thx for your answer but we already uninstalled everything

What we found out is the following:

The "UmbracoContext.Current.Request.Url.Scheme" returns https randomly in the GetDomainIfExists - Method (library.cs).

Does anyone experience the same issue?
Is it a wrong iis config or an asp.net bug?

Not sure if this has anything to do with what you are experiencing, but a similar situation is happening with me and it's because of Macro caching.  Basically, I have some pages that are running in HTTPS, because I have a few forms that post to an HTTPS URL, so when the response is returned from the server, the resulting page is rendered with all of it's links resolved to httpS://mysite.com/whatever.

Now, because my pages contain a whole bunch of Macros that are cached on a per-page basis, if I visit a page via https for the first time (as in the macro has not yet been cached for that page) the macros will be fully rendered with their links set to the current scheme (https).  The next time I visit that page shortly afterwards, but NOT via https, the macro is loaded from cache and therefore contains httpS links, even though the page is being viewed by HTTP (no S).

The end result is maybe something similar to what you are experiencing - navigating round the site with links seemly randomly changing between http and https.

This might explain why when you save the one node, the problem goes away with others - Umbraco empties all of it's Macro cache whenever ANY item is published, to avoid caching inconsistency problems.

This MIGHT be the root of your problem... hope it helps!

I'm with you Tobias - seeing the same behavior when the umbraco backend is running under SSL - every document published gets a primary link of https. Connect via the backend without SSL and they get http links.

I haven't yet run it under the debugger but you're right about library.cs lines 501 and 513 in the 4.7.1 source:

return string.Format("{0}://{1}", UmbracoContext.Current.Request.Url.Scheme, d.Name);

Since UmbracoContext.Current.Request is just a thin wrapper around the Request object - this must always be returning https when the backend request is SSL. And then that gets cached in a static Dictionary for all future calls - resulting in front-end links being SSL incorrectly.

Additionaly, I'm seeing a problem where sometimes internal domains I use are being set as the primary link of documents. For example, I might associate these domains with a root level site:

www.mysite.com.au
mysitepreview.mycompany.com.au

That way when I'm doing maintenance on the site I can redirect requests for www.mysite.com.au but still access the content via mysitepreview.mycompany.com.au so I can confirm things are ok before 'turning it back on'.

However, I access my umbraco backend through a third url:

content.mycompany.com.au

And the problem is that the Domains.GetDomainsById(nodeId) call ultimately calls the database and retrieves all domains without specifing a sort order - so the results are in an arbitrary database order (http://en.wikipedia.org/wiki/Order_by). Since the current hostname does not match any domain in my list, the first domain is used. And since the order is arbitrary, sometimes I'll get links on www.mysite.com.au (what I want) and sometimes they'll be on mysitepreview.mycompany.com.au (not want I want to expose).

So I think there are two fixes to be made in the source and database:

1. Don't use UmbracoContext.Current.Request.Url.Scheme when determining the schema for NiceUrl links. I guess hardcoding it to http is the only answer (and relying on 301s to force SSL where necessary on the frontend according to the site's needs).
2. Specify a sort order on the Domain.GetDomains() call. Without a lot of UI work with drag and drop ordering, this could most easily be solved by adding a DateCreated column defaulting to GETDATE(). Then just order by that. If you want to change the order in the backend UI, you'd have to delete and re-add domains. But at least the first domain would always be the one used where there's no match to the current hostname being requested.

Cheers, Adam.

Hi All.

There is a lot going on in the thread, so I will try to cover everything as much as possible.

When you access the Umbraco back office, are you accessing it on https://?  If so, the urls that have domains added to them (hostnames assigned) will generate the https in the url.  So, if useSSL is set in the web.config, then the urls will show the https.  

The pages should not redirect if no on SSL, and that sounds like either URL rewrites or IIS rewrites are still in place.  If you have a handler or package in place that is causing the redirect, then it is not anything we can fix specifically.  

Things to try:

Reset the app pool.  

Does the default page redirect?
Does the /umbraco/ page redirect?
Verify use SSL is set to False.
What handlers/modules do you have in your web.config? 
What is in the urlRewrite file?

Casey 

Hi Casey,

Here are the steps to reproduce:

1. Download Umbraco 4.7.1.1 binaries from http://umbraco.codeplex.com/releases/view/73692

2. Install into IIS. Configure IIS to listen on http://mydomain.com and https://mydomain.com.

3. Run the Umbraco install procedure (I picked SQL Server as the database but that shouldn't make any difference).

4. Install the Business Starter kit.

5. (Key point) - turn on <useDomainPrefixes>true</useDomainPrefixes> in umbracoSettings.config.

6. Login to the backend using http - ie. http://mydomain.com/umbraco/

7. Attach a hostname to the top level node (Business Site in this case). eg. mydomain.com

8. Republish a document, eg. Business Site/About. Notice the Link to Document is http://mydomain.com/about.aspx.

9. Now logout and login again but this time using SSL in the backend, eg. https://mydomain.com/umbraco/

10. Republish the same document as before - now the Link to Document is https://mydomain.com/about.aspx. And when browsing the front-end site the About link is now in SSL incorrectly.

Note that useSSL has not been changed from the default of false, no additional url rewriting is taking place, and no additional handlers are installed.

As I said before, I think the bug is due to taking the current backend request scheme when building the URL - library.cs lines 501 and 513. This bug only manifests itself when at least one domain has been attached to a node and useDomainPrefixes is set to true.

In addition, as a seperate issue noted above, the domain returned on the link to document is random when there is more than one domain attached to the node, as there is no ORDER BY specified when retrieving domains.

Cheers, Adam.

Hi casey,

Have you been able to reproduce this issue as described above?

Cheers, Adam.

Hi Adam,

This is part of a url caching bug that will be reviewed and corrected.  Thanks for the information.

Please email me for options on a short term fix or patch. 

Casey @umbraco

I have the same issue, Adam seems to have described accurately.

Recycling the app pool fixes the urls.

We have the admin and extranet on one SSL domain, and the public site on another domain (sans ssl)

So the links are seriously broken on the public domain as there is no SSL cert installed. 

Is there a codeplex issue for this?

Cheers.

Murray.

Hi Murray,

I don't think there's a codeplex issue, but I'm happy to send you the interim patch until the next version of 4.7.x comes out (hopefully with this fixed).

Email me at spudstuff at gmail.

Cheers, Adam.

As an alternative, here's a 'hack' workaround:

Edit umbracoSettings.config

set distributedCall enable="true"

and add the domain name of the server you want to be published as to the list, this will probably cause the content to be refreshed twice, but at least it won't have eroneous HTTPS in the URI.

* do this at your own risk

@Adam note: where you have one hostname SSL and another non SSL the patch does not work, but the hack I mention above does seem to do the trick.

However my hack makes the publishing process take a long time. :-\

Yeah but you can always force SSL using a few lines of code inserted into the master template of the site you want to force SSL. The links between pages might indicate http but your redirect will fix that. Means an additional redirect for each page though.

Alternatively you can put whatever logic you want in that NiceUrl replacement:

        public static string NiceUrl(int nodeID)
        {
            string tempUrl = baseNiceUrl(nodeID);
            if (tempUrl.ToLower().StartsWith("https://"))
            {
                // Force http on all URLs generated for nodes, except for myspecialsslsite.com:
                if(!tempUrl.Contains("myspecialsslsite.com"))
                {
                    tempUrl = string.Format("http:{0}", tempUrl.Substring(tempUrl.IndexOf("//")));
                }
            }
            return tempUrl;
        }

Ultimately the real fix is probably for hostnames to also require a scheme when associating them with Umbraco nodes. I've tried that (the domains editor doesn't stop you from putting in https://myspecialsslsite.com as a domain), but the Umbraco request handler didn't match it correctly when the requests came in.

Cheers, Adam.

Yep, my hack was a bit tempramental, so I adjusted the patch you sent like so.

if (tempUrl.ToLower().StartsWith("https://www"))

So it only stripped out the https for the public facing pages.

P.S. thanks for sending that though.

I'm having the exact same problem with Umbraco 4.7.1, does anybody knows if that was fixed in 4.7.2? 

Umbraco 4.7.2

Same or similar problem - pages changing to https 'randomly'. A republish seems to change https pages to http and http pages to https. Uncached all macros which didn't make any difference. 

Doesn't seem to affect our dev environment just production. There are differences mainly ISA so not sure if security is doing something.

Recycling app pool reverts all https to http without republishing. Temporary fix for us is to recycle app pool after each publish. Still looking for proper fix....

Still getting this problem, any solutions? 

We have no clue.  We've had to put in kludgey workarounds to get around it.  

is working on a reply...