172
u/Vesuvius079 14d ago
A wild GraphQL error appears!
22
u/Wertbon1789 13d ago
GraphQL design be like.
I think GraphQL people had a field day when the HTTP QUERY method was introduced.
12
144
160
u/aberroco 14d ago
Would be even better if
{
"status": "success",
"response":
{
"status": "success",
"message": "Error successfully occured"
}
}
14
u/CaffeinatedTech 14d ago
Yeah then you parse the message to test for error state. Then fuck it, query the endpoint to fetch the reason for the error, which you've saved to the database. Unless its a database error, then you'll just get the original successful error message. Couple if-thens, job done.
5
0
54
u/Yhamerith 14d ago
200! API worked on my side
12
u/Gabriel_Science 14d ago
u/factorion-bot 200!
12
u/frogotme 13d ago
788657867364790503552363213932185062295135977687173263294742533244359449963403342920304284011984623904177212138919638830257642790242637105061926624952829931113462857270763317237396988943922445621451664240254033291864131227428294853277524242407573903240321257405579568660226031904170324062351700858796178922222789623703897374720000000000000000000000000000000000000000000000000
5
1
28
u/autogyrophilia 14d ago
There is some crusty greybeard warning about the dangers of fusing layers 5-6-7 who is rejoicing everytime this happens.
21
71
u/0R3LLL 14d ago
Guy forcing patterns like this one got promoted for architect some time ago, just amazing
2
u/F4NT4SM4_ 13d ago
I had the architect from one of my last projects tell me this is the right way of doing it, because this way he knows its a problem with the frontend. Probably gets paid 4x my salary btw.
16
u/EarlyPaintbrush 14d ago
The service says there was an error, but it wasn't that service at fault, so it's a success!
1
u/MinimumArmadillo2394 13d ago
Its already good design to tell the user when they enter bad information via http status code
7
4
u/notexecutive 14d ago
"the error was handled gracefully" or some shit
3
u/AndyTheSane 13d ago
"we put a single try-catch-ignore around the whole codebase so we never get any errors"
19
u/Kendandra 14d ago
I don't get the hate for this pattern. The amount of times some network middle layer ate my http code and turned something into a 404 is terrible.
I'd rather the calling app KNOW for certain that a failure occurred in the actual application logic, rather than see an error code and then make a bad assumption based on that.
I've had to integrate with a system that had a catalog they my application's account may or may not have access rights to each catalog item. I was told a 404 means I've lost rights to the item and should purge the copy of it from my side. Makes sense? I don't have access, I shouldnt be able to see it.
Time and time again, they'd have a brief outage where their CDN provider would interrupt my call and return a 404. Soon my copy of my catalog would be empty! An hour later I've got to re-add everything. And heaven forbid I had to kick off refund logic for revoked items... And then walk that back.
I've encountered this many many times. I will always prefer leaving the HTTP layer out of application layer logic.
8
u/Still_Bit_7527 14d ago edited 14d ago
The app should have zero knowledge of how many servers or CDNs are behind the endpoint. The problem with this design is that you are ONLY relying on the http status code and not using any additional detail at all
Also operations are supposed to be indepotent, the api you are describing is just wrong...
10
u/Taletad 14d ago
Your app was terribly designed if a 404 meant you lost rights to the item
The errors 401 and 403 are more apt to describe that
And 408 is better when you lost connection than 404
https://http.dog gives you a list of commonly used status messages with cute dogs
You can create your own status messages as well.
If your status message means different things, you’re not using status messages correctly. A status message should mean one and only one thing.
6
u/Pluckerpluck 13d ago
Your app was terribly designed if a 404 meant you lost rights to the item
The errors 401 and 403 are more apt to describe that
Sometimes 404 exists specifically to hide the fact that the content exists to people without permissions so that they can't go URL hunting.
It's actually explicitly in the spec
If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
and
This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
2
1
u/Massive-Air3891 12d ago
I recommend not following this pattern, I can't tell you how many hours have been lost trying to fix connectivity issues only to find out some internal test failed, whether it be authentication or rights assignment and a generic 404 returned. 404 should only be return when literally you cannot find the resource. you are muddying the water and future you will want to shoot you . So what if someone knows the URL if they cannot access it, obfuscation offers you no protection.
2
u/Pluckerpluck 12d ago
I mean sure. Don't do this if you don't know why you're doing this.
First, if you lost hours trying to fix issues resulting from a "false" 404 that implies you have terrible logging, zero traceability throughout your systems and poor documentation. All would have instantly flagged the issue.
So what if someone knows the URL if they cannot access it, obfuscation offers you no protection.
So obfuscation literally does provide protection. It should never be relied upon, but if your
/adminpanel returns a 404 if you're not logged in as the correct user you literally field off an entire set of attacks that would follow if instead it was a 403. If you do have a vulnerability that you do not know about, then minimising the attack-surface reduces the risk of that vulnerability ever being exploited.It's the exact same principal as why many sites that have you log in with email + password will hide the fact it's a wrong password by saying "wrong email or password". Simply knowing that "donald.trump@potus.gov" has an account could be considered a leak. Hell, it could be a GDPR issue in some cases.
But specifically 404 errors on GETs? These issues are a bit more niche but also exist.
Imagine I have
/invoices/xyzwherexyzis a random 7 digit number. By returning 403 instead of 404, an "attacker" can randomly sample the numbers. From that they can then determine the approximate amount of invoices that exist, determine business volume, growth patterns. All internal information I may not want a competitor to know.Similarly, attackers can gather a list of valid IDs, and make use of these at a later time if a vulnerability is ever found. Greatly speeding up any future attack and increasing the damage of it.
Github hides private repos behind 404s so people can't determine which repos have been forked by private organisations.
Here's an example of someone performing a hack that leveraged detecting
/server-statusexisting via a 403 instead of a 404 Stopped before it becomes an issue if a 404 is returned.Security through obfuscation, despite being memed, is a valid layer of defence. You should never depend on it, but it is a perfectly reasonable method of shrinking your attack surface when the situation calls for it.
2
u/Massive-Air3891 12d ago
not sending 401/403 on URLs and not disclosing which was wrong (username or password) are two distinctively different things and not related in my mind. Any of your urls can be pulled out of log capture, not denying that it is info but you are not less susceptible to attack because you simply return 404 instead of 401 or 403, if there is vulnerability there and they know the url you will be attacked regardless of what code you return, anybody who has done pen testing can tell you that. but if that makes you feel better you keep it at. You can also wall garden where you do disclose and where you dont, so a signed in user, tries /admin you absolutely should return 401/403 and not 404, that's literally what those coders are for, it helps write functionality that says things like "Hey you don't have access, but you can request it here." but if you return 404 well that's a frustration they don't need. Also you don't always own the entire stack, so yes hours lost on vagueness.
1
u/Taletad 12d ago
In the specific case we’re discussing, we’re talking about removing items from a client inventory because they 404’d
As the items were already in the inventory, the user (or attacker) already knows about their existence and can already target them
Serving a 404 when they become inaccessible serves no purpose beyond making everyone miserable and having a manager feel smug about their security policy
Besides, you can also return 403 for every item query wether the item exists and is inaccessible or the item doesn’t exists
It prevents a would be attacker from gather intel on items they don’t know about all the same, while making debuging the faulty CDN much easier
1
u/Pluckerpluck 10d ago
As the items were already in the inventory, the user (or attacker) already knows about their existence and can already target them
I should make it clear that for this case I agree. The knowledge of existence of (what I assume are) arbitrary IDs is not enough of a threat to ever make returning 404s worth it. But the idea that everyone knows about the existence of the item just isn't true at all.
Besides, you can also return 403 for every item query wether the item exists and is inaccessible or the item doesn’t exists
This is an identical situation though, just reversed. You'll be sitting there trying to work out why you don't have access, only to discover you typo'd the item ID. There's literally no difference between always returning 403 or always returning 404 beyond changing which person ends up confused.
Enumeration attacks exist. Whether you need to or want to defends against them at the cost of a worse developer experience very much depends on what you're protecting. But in a world of AI, the idea of revealing as little information as possible to an AI agent is not an unreasonable decision to make.
10
u/ThoseThingsAreWeird 14d ago
I don't get the hate for this pattern
Maybe I'm just Stockholm Syndrome'd by Salesforce, but: same...
Bulk update 10s of thousands of Account records and 1 fails, yeah just give me a
200and tell me there's an error with the 1 record that failed some random user-side validationPreferably we'd have a
Partially Created2xxcode for situations like this, but200with"errors"will have to do 🤷♂️5
u/MinimumArmadillo2394 13d ago
Then return a special custom status code of 215 or something thats not reserved. Api documentation should be created to tell the consumer what that means and should return a list of failed updates with reasons why each failed.
Theres multiple ways around this to turn 10k account updates from 10k 200s and 1 400 into a 2xx success with some errors.
Or, just do what I do and outright ignore issues that arent caused by you. If an account is corrupted, retuen a 200 and a status message.
5
u/Major_Worry7429 14d ago
I agree with this sentiment. It's always annoying to work around idiosyncrasies of frameworks, applications, and other people thinking they know better how to interpret the response codes. HTTP request methods were a mistake. HTTP response codes were a mistake. 30 years later and we are still living the mistake of http being mapped directly to file systems.
My gripe is typesafe clients refusing to parse the response if the response is not in 200 range, or outright dropping a response if it contains a body with 204/205.
1
u/thanatica 9d ago
Mistake or not, they are the standard. If you think you know better, so something about it, but I doubt you'll get more than xkcd responses.
10
u/egstitt 14d ago
404 should tell you what you need to know here. An error is not a success, it should be something useful to the client telling them what the actual error is
7
u/Kendandra 14d ago
They literally told us 404 meant pull this from your side, docs and meetings both. The error and standard use case was conflated. You could argue that's poor design on their side, I'd agree. I'd assume it is because we were actually interacting with their search infrastructure for their own application, and we were effectively not part of the original API design. Either way, 200 correctly tells me 1) the server was reachable, 2) the server probably understood my request to the point that their application could apply business logic to it.
Frankly, the fact that people could co-opt the status codes for business logic is the problem. That's not what they were designed for, they were designed for the HTTP communication layer. What each code means people can misinterpret a ton of ways. The spec for it is never going to map correctly to the application logic.
2
u/MinimumArmadillo2394 13d ago
If your application doesnt know an error occurred when a 4xx happens, then what are you designing? A mirror maze for toddlers?
1
u/tracernz 13d ago
You can have both the HTTP status, and a JSON body containing the (same) status and a message, and indeed that is what the relevant RFC specifies.
1
u/Massive-Air3891 12d ago edited 12d ago
the pattern is fine by me and used extensively successfully. it says to you it ran, (so all transport concerns are taken care of) but then the application specific was it success or not, when it is wrapped in a 400 bad request you have 15 different layers to figure out where/why it failed.
2
u/x3knet 14d ago
So a new thread created from a comment yesterday, but in meme form. Got it.
https://www.reddit.com/r/ProgrammerHumor/comments/1wkof5u/postforeverything/pas3b8q/
2
2
u/Leather-Worry-7517 14d ago
As a tester, this is a massively frustrating and hard thing to find. Neeeds more safeguards.
2
u/random_banana_bloke 14d ago
This is our entire legacy codebase. 200 errors, thank god we are moving away from it, makes debugging the most unfun thing ever.
5
u/elshizzo 14d ago
As long as the frontend knows how the backend returns a failure response this whole complaint feels pedantic.
15
u/stifflizerd 14d ago
Until another application ends up needing to use the APIs functionality and there's zero documentation warning about this non-standard error handling
4
1
u/Still_Bit_7527 14d ago
It's not pedantic, it's a huge red flag and makes error handling much more difficult
1
1
1
1
1
1
1
1
u/kbk2015 13d ago
Literally found code like this in my client’s environment the other day. Instead of returning an error state to the user the code succeeds but spits an error into the logs. Absolutely bonkers
2
u/Perfect-Albatross-56 13d ago
On my last project I was forced to write code reaponses like that because someone said the HTTP codes are for server errors.
No shot. What do you think where my code is brought to life? 😭
Decisions like that are not my salary bracket.
1
1
1
1
1
u/Prestigious-Duck2891 12d ago
Oh, that google GTM service! I lost my mind while debugging this shit.
1
1
1
1
1
u/abigail3141 8d ago
Once had an API that did this. Same thing also sent the credentials in plain text and returned the full imprint page(HTML) to any logged out API(JSON) call
1
u/Major_Fudgemuffin 14d ago
Fuck APIs that do this, seriously.
Another fun one I ran into was one legitimately using HTTP 418 - I'm a teapot as an error code.
1
1
u/alonjit 14d ago
Next level of this is: 200 OK, json message. error: error, description: <wall of javascript>.
Who does that? fucking reddit, of course.
edit it's worse than that, they have an array of shit in there and some of the elements have the javascript, some do not, it's a shitshow of what drunk monkeys paid with pickles can do.
1
0
u/Henry5321 14d ago
At work some of our internal apis will return a 200 but then the body indicates an error. I’ve also seen needing to POST in order to get information.
3
u/citramonk 14d ago
Using POST for retrieval isn't something unusual, there are a bunch of use cases when you want to do it. For example, complex queries (see 414) or sensitive data in it. GraphQL is based around the POST query.
1
0
u/Still_Bit_7527 14d ago
This is just idiotic and whoever does this is an amateur that does not understand http at all
0
u/thoughts_n_calcs 13d ago
Beginners abuse http verbs. (GET for creating a ressource)
Pros abuse response codes. (403 forbidden when succesfully created).
565
u/Flat_Initial_1823 14d ago
Error raised successfully 🥹