Immich doesnt return http 404
Hi there,
(I'm on the latest server version 1.134.0)
please refer the screenshot. The issue is - For http://immich-local-url:2283/some-url, there should be few 404 http codes in the neetwork tab but all immich returns is 200 😦
I'm trying to setup immich behind nginx with fail2ban and if immich doesnt return correct http error codes, fail2ban will be useless. It does show 404 message but was expecting http code as well. Any idea? is this intentional?
(couldnt find any github issue regarding this)
32 Replies
:wave: Hey @EGG,
Thanks for reaching out to us. Please carefully read this message and follow the recommended actions. This will help us be more effective in our support effort and leave more time for building Immich :immich:.
References
- Container Logs:
docker compose logs docs
- Container Status: docker ps -a docs
- Reverse Proxy: https://immich.app/docs/administration/reverse-proxy
- Code Formatting https://support.discord.com/hc/en-us/articles/210298617-Markdown-Text-101-Chat-Formatting-Bold-Italic-Underline#h_01GY0DAKGXDEHE263BCAYEGFJA
Checklist
I have...
1. :ballot_box_with_check: verified I'm on the latest release(note that mobile app releases may take some time).
2. :ballot_box_with_check: read applicable release notes.
3. :ballot_box_with_check: reviewed the FAQs for known issues.
4. :ballot_box_with_check: reviewed Github for known issues.
5. :ballot_box_with_check: tried accessing Immich via local ip (without a custom reverse proxy).
6. :ballot_box_with_check: uploaded the relevant information (see below).
7. :ballot_box_with_check: tried an incognito window, disabled extensions, cleared mobile app cache, logged out and back in, different browsers, etc. as applicable
(an item can be marked as "complete" by reacting with the appropriate number)
Information
In order to be able to effectively help you, we need you to provide clear information to show what the problem is. The exact details needed vary per case, but here is a list of things to consider:
- Your docker-compose.yml and .env files.
- Logs from all the containers and their status (see above).
- All the troubleshooting steps you've tried so far.
- Any recent changes you've made to Immich or your system.
- Details about your system (both software/OS and hardware).
- Details about your storage (filesystems, type of disks, output of commands like fdisk -l and df -h).
- The version of the Immich server, mobile app, and other relevant pieces.
- Any other information that you think might be relevant.
Please paste files and logs with proper code formatting, and especially avoid blurry screenshots.
Without the right information we can't work out what the problem is. Help us help you ;)
If this ticket can be closed you can use the /close command, and re-open it later if needed.
Successfully submitted, a tag has been added to inform contributors. :white_check_mark:It's all rendered frontend, so you get the same response (with the app code) no matter which address you go to and then the code in the frontend looks at the path and decides what to do
So a 404 code doesn't apply there
so shouldn't frontend return 404 if path doesnt exists?
its definitely not normal behaviour
It's definitely normal, just not what you want/expect
Ok... Appreciate it.
I'm not sure if this thread is dead or not but... From what I can tell, it is standard to still return a 404 status code even when it is rendered on the frontend. Since Immich isn't returning the actual status code, it makes it difficult to detect 404 attacks / unwanted scanning.
If it's being rendered in the browser, there are no status codes involved and any server side monitoring you have is categorically unable to see what's happening there
Ok, so it sounds like this is a limitation of the current tech that Immich is using. Where a valid page is returned that somehow checks on the frontend if the path is found or not.
I understand your point @bo0tzz but.... Say if there is a DOS attack on with 404/401/403 endpoints, it'll bring down frontend and backend too cause backend would be overwhelmed with so many 200 requests (even though they are say 404 on frontend).
Issue is how do I prevent this scenario? Cause I can only setup monitoring on backend not the frontend.
Have more monitoring than just looking for 404s then?
Like request ratelimits and such
But also, nobody is going to DoS you
404 was just an example. 🤦
Ratelimits are already set with large threshold for genuine requests and small threshold for malicious ones but clearly even the malicious ones are being categorized as genuine.
closing post as there is no point to continued discussion.
But also, nobody is going to DoS you🤦
closing post as there is no point to continued discussion.
Returning the correct status code is of huge importance, and even more when speaking about security. I have been using Immich for a while now, and i have been slowly adding more users to my instance (my partner, my mom, my dad, my siblings...) as this grows im taking security more serious but after reading this thread im shock, like im guessing security is not that important for immich after reading the answer: "Have more monitoring than just looking for 404s then?"
Security is definitely important, this is just a non-issue
If you want to get technical, at the end of the day, there is an http request for the immich web app html and it successfully returns a 200 response code with said html. They have not accessed an actual server-side resource that doesn't exist. This is probably just a limitation due to the fact that this is a single page application.
The most important thing to monitor is http request for server-side resources that result in http errors (4xx). Specifically, resources that hit /api/*. There are zero security implications for actors accessing static, pre-built frontend resources.
I’ll plan to open a FR outlining that this isn’t currently possible but if we switch to server side rendering at some point we can revisit
got it. saying it cant be fixed with current lay of the land is one thing vs saying - "this is just a non-issue" are two completely different things. Its very clearly an issue but understandably it cant be fixed until immich moves to server side rendering.
Clearly an issue is a bit subjective. Clearly depends on what you consider an issue. I think we can agree to disagree on that
If it was a server rendered page then in the response would be data you didn't have access to and so you would throw an appropriate error. That's just not the case for a SPA.
just to expand on this -
when a user make a request to say
https://example.com/s/album-doent-exists , the frontend in turn calls /api/server/feature , /api/server/config etc endpoints. so far so good?
now in the logs, all the 4xx /api/* calls are the server IP. But frontend calls from client IP return 200. So how I can rate limit or do anything with fail2ban??
monitoring /api/* does nothing! cause, i'll say it again, ALL /api/* are from server IP which I cannot be ratelimit/block etc 🤷♂️ hence clearly an issue. but lets agree to disagreeI'm not sure what you're saying with "server IP" but the client is making those requests to the server
So you definitely know which client made that request
/_app/* are from client IP which are 200 in logs & `/api/* are from server IP which 4xx in logsCan you send of screenshot of what you are talking about?
Yes and?
Wait now you updated that message
That doesn't make any sense
So yes please send a screenshot
sure few mins
Specifically /share/key is server side rendered and should return a 404. /s/slug should be as well but I think we forgot to add that.
Are you using a reverse proxy?
yes
Are you seeing everything with that server's IP in your logs?
yes! this seems to be the case currently!
Can you clarify what you are referring to when you say server ip vs client ip
You can open a bug for this route specifically. It should work the same as /share/key.
this wasnt the case when I had created this support case. But now I can use f2b, etc on
/share/ & /s/
and non /api routes throw wrong code until immich moves to server side rendering...API routes always will be correct response codes.
Oh it says non-api now.
Yes they will always be 200, with the exception of /s and /share
If you are monitoring immich logs for ips you should make sure you have IP address forwarding on so every request isn't logged with the IP of your reverse proxy.
https://immich.app/docs/administration/reverse-proxy
thats enabled. in the logs above,
/s/* is from correct IP (client ip)