Comments (14)
Make sure your Nginx configuration is correctly set up to proxy WebSocket connections. In your Nginx configuration, you should have a section similar to this:
location / {
proxy_pass http://your_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
from linkstack-docker.
All these directives are already present. In case you missed it, I've added a summary of my nginx hostfile to the OP. The copy here was missing the proxy_pass directive, which is obviously present in the actual config, but I've added it to the OP for your convenience. Again, all four of these are already set and have been for the entirety of my testing.
from linkstack-docker.
Are you using the internal IP for the proxy_pass?
from linkstack-docker.
No, I am using the container name:
proxy_pass https://linkstack:443;
from linkstack-docker.
What does your NGINX error logs say?
from linkstack-docker.
from linkstack-docker.
What does your NGINX error logs say?
The main thing i see are errors regarding fonts. Filtering those out, this is what remains:
cat /var/lib/docker/volumes/nginx_nginx/_data/logs/proxy-host-48_error.log | grep -v "woff2"
2023/11/07 15:46:54 [warn] 92092#92092: *452094 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/6/67/0000006676 while reading upstream, client: 172.71.103.94, server: bytebones.dev, request: "GET /assets/webfonts/fa-solid-900.woff2 HTTP/2.0", upstream: "https://172.19.0.12:443/assets/webfonts/fa-solid-900.woff2", host: "bytebones.dev", referrer: "https://bytebones.dev/"
2023/11/07 15:50:50 [warn] 92092#92092: *452134 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/7/67/0000006677 while reading upstream, client: 172.71.99.5, server: bytebones.dev, request: "GET /assets/webfonts/fa-solid-900.woff2 HTTP/2.0", upstream: "https://172.19.0.12:443/assets/webfonts/fa-solid-900.woff2", host: "bytebones.dev", referrer: "https://bytebones.dev/"
2023/11/07 15:51:07 [warn] 92092#92092: *452202 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/8/67/0000006678 while reading upstream, client: 172.71.99.71, server: bytebones.dev, request: "GET /assets/css/maps/hope-ui.min.css.map HTTP/2.0", upstream: "https://172.19.0.12:443/assets/css/maps/hope-ui.min.css.map", host: "bytebones.dev"
This does not seem related to websockets. Note that nginx is set to log anything with the "warn" level or above.
The access log shows this when loading the dashboard:
[07/Nov/2023:15:54:44 +0000] - 403 403 - HEAD https bytebones.dev "/.env" [Client 172.71.250.22] [Length 0] [Gzip -] [Sent-to linkstack] "-" "-"
[07/Nov/2023:15:54:45 +0000] - 403 403 - HEAD https bytebones.dev "/database/database.sqlite" [Client 172.71.250.68] [Length 0] [Gzip -] [Sent-to linkstack] "-" "-"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/dashboard" [Client 172.70.47.18] [Length 15509] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "https://bytebones.dev/studio/links"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/fonts/Inter/inter-latin-400-normal.woff2" [Client 172.70.47.8] [Length 16708] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "https://bytebones.dev/dashboard"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/fonts/Inter/inter-latin-700-normal.woff2" [Client 172.70.46.77] [Length 17784] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "https://bytebones.dev/dashboard"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/css/maps/customizer.min.css.map" [Client 172.70.47.17] [Length 3453] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/fonts/Inter/inter-latin-500-normal.woff2" [Client 172.70.47.55] [Length 17552] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "https://bytebones.dev/dashboard"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/css/maps/dark.min.css.map" [Client 172.70.47.17] [Length 20596] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/css/maps/rtl.min.css.map" [Client 172.70.47.17] [Length 18961] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/css/maps/custom.min.css.map" [Client 172.70.47.17] [Length 17885] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 200 200 - GET https bytebones.dev "/assets/css/maps/hope-ui.min.css.map" [Client 172.70.47.17] [Length 156570] [Gzip -] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 404 404 - GET https bytebones.dev "/assets/js/popper.min.js.map" [Client 172.70.47.17] [Length 2299] [Gzip 2.87] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
[07/Nov/2023:15:54:45 +0000] - 404 404 - GET https bytebones.dev "/assets/js/bootstrap.min.js.map" [Client 172.70.47.18] [Length 2299] [Gzip 2.87] [Sent-to linkstack] "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" "-"
note the two 404s, as well as the requests for the .env and sqlite file for whatever reason? The log from inside the linkstack docker container is identical though.
from linkstack-docker.
I have tested it on different servers. Docker and native.
Websocket must be supported by the software, not every software automatically has Websocket.
the 404 is normal because if a client will browse directly to this file they will get a 404 -> not allowed
from linkstack-docker.
Your reply confuses me on multiple levels
I have tested it on different servers. Docker and native.
Websocket must be supported by the software, not every software automatically has Websocket.
Linkstack is supposed to have websocket support, no? Otherwise it wouldnt be a documented feature. Or are you saying that Websockets are supported when running natively, but not in docker? I also want to reiterate that I am running multiple other services with the exact same setup that successfully utilize Websockets, like Vaultwarden. So there's no point in blaming my setup alltogether, it definitely can work. And if you're trying to blame my browser - its a very normal chromium browser, and WebSockets have not caused issues on any other site.
the 404 is normal because if a client will browse directly to this file they will get a 404 -> not allowed
The 404 cannot be normal. Why would the website be programmed to access files that are not available on the server, when both client and server have been programmed by the same people? Plus, a 404 is not a "not allowed" error, its a "does not exist" error.
And if you mistyped and meant the two 403s instead - why is the client programmed to access data that is reserved to the server backend? Or is that untrue and the two files are technically accessible through the webserver? which would be not good at all...
from linkstack-docker.
Linkstack is supposed to have websocket support, no? Otherwise it wouldnt be a documented feature. Or are you saying that Websockets are supported when running natively, but not in docker? I also want to reiterate that I am running multiple other services with the exact same setup that successfully utilize Websockets, like Vaultwarden. So there's no point in blaming my setup alltogether, it definitely can work. And if you're trying to blame my browser - its a very normal chromium browser, and WebSockets have not caused issues on any other site.
*Offtopic on *
Websockets for Valtwarden needs to be activated in the .env file
WEBSOCKET_ENABLED=${WEBSOCKET_ENABLED}
but normally the Websocket is not activ
Offtopic off
I need to check if there is Websocket funtcionallty
And if you mistyped and meant the two 403s instead - why is the client programmed to access data that is reserved to the server backend? Or is that untrue and the two files are technically accessible through the webserver? which would be not good at all...
You are Right normally it could be a 403 because of deny via htaccess
we will check this
but technically only the websever himself need the access to this files not the user
from linkstack-docker.
*Offtopic on *
Websockets for Valtwarden needs to be activated in the .env file
WEBSOCKET_ENABLED=${WEBSOCKET_ENABLED}
but normally the Websocket is not activ
Offtopic off
Still offtopic, but Vaultwarden recently moved their WebSocket implementation from port 3012 to 80, and it is now enabled by default.
I need to check if there is Websocket funtcionallty
Do you mean that you're checking if there is WebSocket functionality in Linkstack? When Websockets are part of the documentation since, at least, august 2022?
You are Right normally it could be a 403 because of deny via htaccess
we will check this
but technically only the websever himself need the access to this files not the user
I had a look into the files stored by linkstack in htdocs, and was surprised to find the .env and .sqlite files there - though they are indeed blocked via the .htaccess file. It feels weird to me to have these completely internal files technically accessible through the webserver (imagine a zero-day exploit that can circumvent the .htaccess rules for example), and I would imagine those files to be stored completely away from the webserver so they're 100% inaccessible without access to the server hardware - but maybe thats just how PHP works, it's really not my cup of tea after all.
from linkstack-docker.
Do you mean that you're checking if there is WebSocket functionality in Linkstack? When Websockets are part of the documentation since, at least, august 2022?
laravel supports Websocket, but it is not implemented in Linkstack.
from linkstack-docker.
If WebSockets were never implemented in Linkstack, I wonder why they're part of the reverse proxy configuration. I also wonder if that means that this behaviour when switching pages is intended, or if it's just been ignored all this time:
Bildschirmaufnahme.2023-11-10.um.17.49.34.mov
Until now I thought that this must be because of the missing WebSockets, and that having them work would enable a smoother page switching experience. Especially since this also happens every time you change any setting on any page, which gets very hard on the eyes after adding a couple links to your page.
I guess not then?
from linkstack-docker.
LinkStack does not support WebSockets natively, and there are no plans of implementing this. The reverse proxy block is just a generic template.
LinkStack renders over static HTML elements. What you are experiencing is the intended behavior. This cannot be changed without rewriting pretty much the whole app.
We have plans to change some parts of the frontend in 5.0. Stay tuned for any updates to come.
from linkstack-docker.
Related Issues (20)
- `Spatie\Backup\Events\BackupHasFailed` HOT 4
- LinkStack has problems with links as soon as 'custom locations' are specified in the NGINX reverse proxy HOT 15
- Resend Verification email loop HOT 7
- Number of Links in Userlist HOT 1
- Multiple Pages Per User [Feature Request] HOT 1
- SSL Certificates HOT 2
- Permission denied on httpd.conf on Startup HOT 5
- [Sun Jan 07 13:43:21.961240 2024] [httpd.conf] ::1 - - "GET / HTTP/1.0" 400 450 "-" "-" HOT 1
- htdocs directory not populating with persistent volume HOT 13
- cant deploy HOT 11
- Update image HOT 1
- Fonts returning 404 when trying to add a link
- Can't bind the /htdocs folder to outside of container HOT 2
- i want to add a web sdk to my linkstack page, how should i do it, which file should i add HOT 4
- I cant run container console HOT 4
- Cannot get favicon.ico from a specific site HOT 2
- Cannot run backup or auto-updater HOT 1
- Unable to Edit Links HOT 5
- Unable to add links HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from linkstack-docker.