Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial![](https://ecs-static.teamtreehouse.com/assets/views/marketing/shared/community-banner-white-47072046c51352fe6a69f5e691ff5700b28bb11d45197d7bdf066d9ea3f72d0c.webp)
![Luis Marsano](https://secure.gravatar.com/avatar/a0c23ecad9485497d2bc99b81dc7fb79?s=96&d=https%3A%2F%2Fecs-static.teamtreehouse.com%2Fassets%2Fcontent%2Fdefault_avatar-445fbbabfc8dc9188fb5967fe43322ee0c3e0dd1e10f378bf8343784af5a13eb.webp&r=pg)
Luis Marsano
21,425 PointsStatus code 401 seems incorrect. Is there a better solution?
IANA lists standard status codes and their specifications. According to the specification for status 401
The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.
Our code doesn't do that. In fact, if we read the rest of the specification, it becomes clear the status code is for an HTTP Authentication framework we aren't using: HTTP Authentication is performed through HTTP headers, whereas we're performing authentication through the HTTP body (of POST requests).
What's a more standards-compliant way to handle authentication failures?
3 Answers
![Vitaly Khe](https://secure.gravatar.com/avatar/65eaad40f79c4c616d2add40bdcc072d?s=96&d=https%3A%2F%2Fecs-static.teamtreehouse.com%2Fassets%2Fcontent%2Fdefault_avatar-445fbbabfc8dc9188fb5967fe43322ee0c3e0dd1e10f378bf8343784af5a13eb.webp&r=pg)
Vitaly Khe
7,160 PointsThank you!
Very important information. I'm discovering the ways of auth now.
https://blog.risingstack.com/web-authentication-methods-explained/
It would be nice if Treehouse had the special course for authentication in web and which type to choose in dependence of scenario.
![Vitaly Khe](https://secure.gravatar.com/avatar/65eaad40f79c4c616d2add40bdcc072d?s=96&d=https%3A%2F%2Fecs-static.teamtreehouse.com%2Fassets%2Fcontent%2Fdefault_avatar-445fbbabfc8dc9188fb5967fe43322ee0c3e0dd1e10f378bf8343784af5a13eb.webp&r=pg)
Vitaly Khe
7,160 PointsThank you! great notice about response. But why you mentioned about the way we send data?
Authentication framework we aren't using: HTTP Authentication is performed through HTTP headers, whereas we're performing authentication through the HTTP body (of POST requests).
Yes we send it in body of a request, but i didn't find a requirement that points the authentication through HTTP headers. Could you give a point?
![Luis Marsano](https://secure.gravatar.com/avatar/a0c23ecad9485497d2bc99b81dc7fb79?s=60&d=https%3A%2F%2Fecs-static.teamtreehouse.com%2Fassets%2Fcontent%2Fdefault_avatar-445fbbabfc8dc9188fb5967fe43322ee0c3e0dd1e10f378bf8343784af5a13eb.webp&r=pg)
Luis Marsano
21,425 PointsSpecs/standards say the right way to do things. They don't usually require you to follow them or prohibit you from not following them. They're like recipes: a recipe telling you to freeze ice cream probably won't specifically prohibit you from baking it, but a failure resulting from doing so shouldn't surprise anyone.
We're sending authentication data through the body and generating 401 responses. Where in the spec does it say 401 responses are to be used in that way? The only spec on 401 responses doesn't mention authentication through bodies anywhere
A 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent
and
A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401 (Unauthorized) — can do so by including an Authorization header field with the request.
What it does say we can do (authenticate through headers), we're not doing. What we actually do (send authentication through the body), it never tells us to do, certainly not in that way. Though it says we can use additional authentication mechanisms (eg, encapsulate authentication within the message), we're still not doing what it specifically told us to do (use 401 responses with special headers). If we're not using those headers, then I don't know what we're doing with 401 responses: maybe baking ice cream.
![Vitaly Khe](https://secure.gravatar.com/avatar/65eaad40f79c4c616d2add40bdcc072d?s=96&d=https%3A%2F%2Fecs-static.teamtreehouse.com%2Fassets%2Fcontent%2Fdefault_avatar-445fbbabfc8dc9188fb5967fe43322ee0c3e0dd1e10f378bf8343784af5a13eb.webp&r=pg)
Vitaly Khe
7,160 PointsCould you pls share - how to autenticate with request that sends authentication credentials (username/password) in header? Is it possible?
![Luis Marsano](https://secure.gravatar.com/avatar/a0c23ecad9485497d2bc99b81dc7fb79?s=60&d=https%3A%2F%2Fecs-static.teamtreehouse.com%2Fassets%2Fcontent%2Fdefault_avatar-445fbbabfc8dc9188fb5967fe43322ee0c3e0dd1e10f378bf8343784af5a13eb.webp&r=pg)
Luis Marsano
21,425 PointsYes, it's possible. It's also not a good idea. Though I don't know all HTTP authentication schemes, the ones I know are dated and insecure, so I don't recommend it. If you must do so, however, try searching for HTTP authentication middleware.
Definitely don't do basic auth: no encryption whatsoever. Digest, though it encrypts (weakly), is highly vulnerable. There might be better HTTP authentication schemes, however: I don't claim to know them all.