-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only use https links in HTML #401
Comments
yeah, but that means to have https enabled domains. E.g. mine isn't. And now to just link to them using https result in a SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE and in newer browser you cannot ignore that, meaning you can't lookup the page. |
The solution for the team-page, to have get a green secure lobid page, would be in not embedding pictures taken from http-domains but e.g. to copy the pictures locally and serve them from there. |
I was just talking about the links from the team page to the individual profiles. They are always http. |
Not all links are already https enabled. Those who are should be used, though. See #401.
This changes the landing page, bot german and English version. Not all links are already https enabled. Those who are should be used, though. See #401.
Currently, the "language" icon (🌎) and the "information" icon (🛈) are broken in both chrome and firefox when viewing the non-https version, see http://lobid.org/. This would be solved when using https everywhere for this page (and for the landing apges of the three services). |
I think we should solve this issue with a redirect (https only) for the landing pages of lobid, team and the three services. |
Re "icons": these were fixed by setting the CORS header. @acka47 please ack. |
+1 |
As switching to https everywhere with #352 wasn't a good idea, we should at least only use https links in the HTML (and maybe add redirects for
lobid.org
,lobid.org/resources
,lobid.org/gnd
andlobid.org/organisations)
so that at least browsers have https everywhere.[Edit: As I misunderstood how the pages currently work (i.e. with relative links), this issue comment was completely bogus at first. It's better now.]
Currently all three services use relative links, i.e. when you are on a http page the links are http, on a https page, the links are https. It would be great to enforce https links everywhere, even if you are starting on a http page.
Please open separate issues in the corresponding repos if needed.
The text was updated successfully, but these errors were encountered: