X3Photo Gallery Forums

RBachmann wrote:I activated HTTPS on my website and was surprised that the colour of my font colour changed compared to non-https. So I activated console logging. Could you please have a look at it?

There are a few questions in there ...

First of all, the good news , is that even though the CDN (CSS/JS) fails (for whatever reason), it manages to fallback to css/js loaded from local server, so the application still works. I think that is kinda cool.


Next, it should automatically be loading the HTTPS version of the cdn CSS+JS if you are on HTTPS (SSL). The only reasons this would fail, would be one of the following: A) Cache. Please try to force refresh the page-cache by making a change to any page, and saving. B) For some reasons, SSL fails to detect on your server, in which case I would like to diagnose.

RBachmann wrote:the colour of my font colour changed compared to non-https.

Even if it did load assets from local instead of CDN, I don't see how that would affect your font color. Both CSS files are identical. Got screenshots?

If you don't mind, I would appreciate getting login to your panel so I can check some things.

Looking at your website now, it's all working nicely, loading resources correctly from https/SSL.


However, I see you also have a none-SSL version of the website running at http://www.240.ch/x3/, which explains the issue 100%. First of all, I don't know why you have BOTH ssl- and none-ssl versions of your website. You are aware that the web (google, bots, etc) considers https vs none-https as separate websites? Technically, they could point to two different locations on your server.

So why is this additionally an issue with X3?
Your issues have a simple explanation, and are related to cache. Since you are running the website from two protocols (two web addresses), it will cache page-data based on ONE of the requests. In previous case, pages were cached from non-SSL, and when running from SSL, it is outputting non-SSL data, including trying to load CDN resources from non-SSL. It would work vice-versa, because it is safe to request SSL resources from non-SSL. Furthermore, there are other issues ... Google SEO is served mixed up content of page- and image-paths changing from https one day to http the other. Not good!

Basically, you should NEVER have two separate urls for the SAME pages!

Fix
The fix is simple. In htaccess make a redirect from one of the protocols to the other, forcing EITHER https or http ... Don't allow both! Your server clearly supports SSL (https), so why not stick with that? It would be something like this: PS! You will need to save something in one page after adding the above, to make sure cache is refreshed.

Also in my domain's root, theres a index.php file to forward all root-requests to /x3/:

Gonna be honest with you, I don't quite understand why you need to use a redirect in the first place. Redirecting delays the server response, and it needs to make two requests to get to a URL. Especially slow if you need an intermediate PHP request to redirect. Why you don't have X3 in the root of your domain if you are redirecting it anyway? Apart from this, the only thing your index.php does, is redirect a request if it lands in root ... It does not force SSL for ALL request on your server, as is what you need. For example, this image works:
http://www.240.ch/x3/render/w480-c1:1-q ... PR0581.jpg

All requests should be forced to use HTTPS.

RBachmann wrote:To be able to access the gallery by just entering the host/domain of the website, I configured my .htaccess as follows:

Code Select all

[root]/.htaccess:
RewriteEngine On
RewriteCond %{HTTPS} =off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L,R=301]

Not quite sure where you have added this, or why you didn't use my example, but this isn't having any effect. The only thing that is working, is your index.php redirect.

RBachmann wrote:All of them are now redirected to https://(www.)240.ch/x3/

That is just because of your index.php, which does nothing more than redirect the root url.

RBachmann wrote:What doesn't work is if a user browses to http://240.ch/x3/ directly, this call isn't redirected by the root-htaccess to https://...
That makes sense as the user didn't request the root of the domain, right.

It makes sense because your htaccess rule does not have any effect, and im not sure why you didn't use my example. My examples forces ALL requests to ANY page/file/root/subfolder, and forces the request to SSL/HTTPS. This is how it should be.

RBachmann wrote:To cover this case, I would have to edit the x3's own .htaccess file in [root]/x3/.htaccess, what I would like to avoid. Editing an application's files bears the possibility to get overridden by a future version of x3.

Sure, but I don't see why you can't make an edit to htaccess in the root folder. Even if you needed to edit .htaccess from X3, this is the only way to achieve a proper canonicalization of your dual access (http and https). Ultimately, this should be controlled from your apache config anyway, forcing this domain to only use SSL. Personally, I use Cloudflare, and a simple page-rule "Force SSL for all requests".

RBachmann wrote:Wouldn't it make sense to have an option in x3's panel to enforce redirects from http-requests to https? This way the application's logic (the .htaccess) file wouldn't need to be touched and maintained by the clients.

This is not something we can manage through PHP/application logic. First of all, redirect from PHP is incredibly slow and ineffective, and is not something anyone should apply to PHP instead of using htaccess. But more importantly, what about image requests and all other non-app specific requests? Imagevue X3 doesn't have any control of these requests. Only the .htaccess file native to your Apache server can route and rewrite requests properly and effectively. Basically we don't want to add redirects at all the X3, as that would be no more than slow hacks to compensate for issues which should not exist in the first place, or be solved by htaccess.

With htaccess, you could even setup a redirect to X3 instead of using index.php (slow). Even better, if you for some reason really need to have X3 in a subfolder although you are redirecting your domain there anyway, you could setup a "rewriterule" ... This is much faster than redirect, as it doesn't require redirect, and basically the "x3" segment in the url would simply be removed, while you can still keep the physical folder.

Unfortunately, my knowledge in creating htaccess rules is below par, but if you provided FTP to your server, I could try to set it up properly.

RBachmann wrote:Also in my domain's root, theres a index.php file to forward all root-requests to /x3/:

I don't quite understand why you need to use a redirect in the first place. Redirecting delays the server response, and it needs to make two requests to get to a URL. Especially slow if you need an intermediate PHP request to redirect. Why you don't have X3 in the root of your domain if you are redirecting it anyway? Apart from this, the only thing your index.php does, is redirect a request if it lands in root ... It does not force SSL for ALL request on your server, as is what you need. For example, this image works:
http://www.240.ch/x3/render/w480-c1:1-q ... PR0581.jpg

All requests should be forced to use HTTPS.

RBachmann wrote:To be able to access the gallery by just entering the host/domain of the website, I configured my .htaccess as follows:

Code Select all

[root]/.htaccess:
RewriteEngine On
RewriteCond %{HTTPS} =off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L,R=301]

Not quite sure where you have added this, or why you didn't use my example, but this isn't having any effect. The only thing that is working, is your index.php redirect.

RBachmann wrote:All of them are now redirected to https://(www.)240.ch/x3/

That is just because of your index.php, which does nothing more than redirect the root url.

RBachmann wrote:What doesn't work is if a user browses to http://240.ch/x3/ directly, this call isn't redirected by the root-htaccess to https://...
That makes sense as the user didn't request the root of the domain, right.

It makes sense because your htaccess rule does not have any effect, and im not sure why you didn't use my example. My examples forces ALL requests to ANY page/file/root/subfolder, and forces the request to SSL/HTTPS. This is how it should be.

RBachmann wrote:To cover this case, I would have to edit the x3's own .htaccess file in [root]/x3/.htaccess, what I would like to avoid. Editing an application's files bears the possibility to get overridden by a future version of x3.

Sure, but I don't see why you can't make an edit to htaccess in the root folder. Even if you needed to edit .htaccess from X3, this is the only way to achieve a proper canonicalization of your dual access (http and https). Ultimately, this should be controlled from your apache config anyway, forcing this domain to only use SSL. Personally, I use Cloudflare, and a simple page-rule "Force SSL for all requests".

RBachmann wrote:Wouldn't it make sense to have an option in x3's panel to enforce redirects from http-requests to https? This way the application's logic (the .htaccess) file wouldn't need to be touched and maintained by the clients.

This is not something we can manage through PHP/application logic. First of all, redirect from PHP is incredibly slow and ineffective, and is not something anyone should apply to PHP instead of using htaccess. But more importantly, what about image requests and all other non-app specific requests? Imagevue X3 doesn't have any control of these requests. Only the .htaccess file native to your Apache server can route and rewrite requests properly and effectively. Basically we don't want to add redirects at all the X3, as that would be no more than slow hacks to compensate for issues which should not exist in the first place, or be solved by htaccess.

With htaccess, you could even setup a redirect to X3 instead of using index.php (slow). Even better, if you for some reason really need to have X3 in a subfolder although you are redirecting your domain there anyway, you could setup a "rewriterule" ... This is much faster than redirect, as it doesn't require redirect, and basically the "x3" segment in the url would simply be removed, while you can still keep the physical folder.

Unfortunately, my knowledge in creating htaccess rules is below par, but if you provided FTP to your server, I could try to set it up properly.[/quote]

RBachmann wrote:As I understood you, your example link http://www.240.ch/x3/render/w480-c1:1-q ... PR0581.jpg shouldn't work anymore with your .htaccess file, right? I see that I'm still able to load the picture through HTTP and I'm not forced to HTTPS.

It should "work", but it would be redirected to https/ssl. The whole point is to make sure there are NO http-requests going on at all ... why would you allow mixed-protocol access to your website anyway? After implementing this properly, SEO would pick up https-ONLY links, and you wouldn't have any links to http anyway ... The redirect would just be a precaution to ensure ALL requests ALWAYS go through https. It's just the right way to do it, by entirely removing http ... The only reason you are not technically "disabling" http, is because it makes sense to catch stray requests and forward them to https-version.

RBachmann wrote:This is my current config in [root]/.htaccess:

Code Select all

RewriteEngine On 
RewriteCond %{SERVER_PORT} 80 
RewriteRule ^(.*)$ https://www.240.ch/x3/$1 [R,L]

And it's not working? I really don't know what's going on here, so I would have to take a look. I do know that you would NOT need to include the /x3/ segment in your above code. The "Force-SSL" should be on a global level for your entire domain ... Any reason why you would want to serve some http here and some https there, while having the same content accessible on both links?

RBachmann wrote:To answer your question why x3 resides in a subdirectory: I just don't like tons of folders in my web-root. Unfortunately my hoster doesn't support to point the domain-root directly into a subdirectory of web-root. That's why I put x3 in its own folder and adjusted your .htaccess-file with "...ch/x3/$1".

That is understandable. These "other" folders in your web-root though, do you mean none-X3 stuff? In which case, may I ask what purpose they have? The by far BEST solution if you need to contain stuff in a folder, is to use a .htaccess rewriterule ... With this, you would basically point to the root domain internally to /x3/. Although the url will NOT include the /x3/ segment, it would run from that path ... This is not a redirect, so it is faster and better practice. In any case though, you should avoid php redirects.

Also, would the /x3/ path be temporary? Not only does PHP require an additional page request, but it's not good for SEO either.

RBachmann wrote:Is there still a possibility to force the visitor to https in this setup?

Certainly. Sorry, but I would need to try on your server to achieve the correct setup, as my knowledge is limited and I can't give you details without being able to see the results instantly. You should be able to achieve redirect from http to https AND rewrite to the X3 path through htaccess.

You could keep your existing setup and redirect to /x3/ subfolder, but we still need to get http-to-https going for ALL requests, and it should still all be handled by htaccess.