Weird https page #59

Activity

1. MagicLike

   transferred this issue fromLinkStackOrg/LinkStackon May 18, 2023
2. MagicLike

   added

   bugSomething isn't workingSomething isn't working

   on May 18, 2023
3. JulianPrieber

   added

   duplicateThis issue or pull request already existsThis issue or pull request already exists

   and removed

   bugSomething isn't workingSomething isn't working

   on May 18, 2023
4. JulianPrieber commented on May 18, 2023

   

   JulianPrieber

   on May 18, 2023

   Member

   More actions

   This error is widely documented here.
   Please use HTTPS for your reverse proxy, not HTTP as stated in the docs.
   You can try to turn on force HTTPS in your config and see if that fixes it.
5. zarevskaya commented on May 18, 2023

   

   zarevskaya

   on May 18, 2023

   Author

   More actions

   Thank you, I check again :)

   👍React with 👍1Reacted by Julian Prieber
6. azukaar commented on May 18, 2023

   

   azukaar

   on May 18, 2023

   More actions

   @JulianPrieber they are using HTTPS in the reverse proxy, but are getting "mixed content" errors because linkstack continues to send HTTP files over HTTPS.

   I am the dev of the reverse proxy they are using, how does linkstack decides what protocol to use? May be the proxy is not sending a header that linkstack expects?
7. JulianPrieber commented on May 18, 2023

   

   JulianPrieber

   on May 18, 2023

   Last edited by JulianPrieber

   Member

   More actions

   LinkStack doesn't really 'decide' on what protocol to use. It simply responds in whatever protocol it's accessed with.
   If you access the page over something like proxy_pass http://127.0.0.1:80; all URLs will be generated as HTTP.
8. azukaar commented on May 18, 2023

   

   azukaar

   on May 18, 2023

   More actions

   Ah so you are deciding depending on the inbound request? Isn't that going to cause an issue with every reverse proxy unless you use HTTPS between the reverse proxy and LinkStack, no? Or may be I misunderstood.

   If that's the case, with your answer I am assuming that this is not the first time you see the issue. I am assuming that you have a reason not to use relative path (which would solve the issue already). So one easy solution is to set the links to start with //. If you do this, the browser itself is going to decide whether to use HTTP or HTTPS, so even if Linkstack is served with

   User -> HTTPS -> Proxy -> HTTP -> LinkStack

   Then the browser will simply use HTTPS to request the files (and the proxy will translate to HTTP)

   Something like

   <script src="//mydomain.com/myfile.js"
   

   Doc here: http://www.ietf.org/rfc/rfc3986.txt

   👍React with 👍1Reacted by zarev
9. JulianPrieber commented on May 18, 2023

   

   JulianPrieber

   on May 18, 2023

   Member

   More actions

   That's right.
   Relative paths aren't currently viable for us. Maybe in the future we can work something out, but as of now we have to let the user use this specific setup to avoid mixed content errors.
10. azukaar commented on May 18, 2023

    

    azukaar

    on May 18, 2023

    More actions

    Note that starting with // are still absolute path, but they will fix your issue for good with mixed contents
11. LinkStackOrg

    locked and limited conversation to collaborators on May 21, 2023
12. JulianPrieber

    converted this issue into a discussion #61 on May 21, 2023