I'm working with an API and recently something went wrong with the authentication.
The API uses jwt authentication, and when POSTing the client jwt request, instead of getting back an auth jwt, I'm getting a 401 (final) status code (or 404, depending on the library I use to handle requests...), but I'm also getting 407 and 200 when setting a verbose traceback?
I'm pretty new to handling HTTP requests so I'm curious how exactly that might be happening, where are those additional two status codes coming from?
Related
I have some code that looks at "Basic Authorization" requests from many different sites.
I want to know if I can make the following assumptions:
A successful response (credentials are correct) will always have response code 200 OK
A failed response (incorrect credentials) will always have response code 401 Unauthorized
Are the above fair assumptions, or is the success/fail conditions configurable per site?
No, there are other possible response codes.
According to the official spec, there can also be the error code 407.
Also, on MDN:
If a (proxy) server receives invalid credentials, it should respond with a 401 Unauthorized or with a 407 Proxy Authentication Required, and the user may send a new request or replace the Authorization header field.
If a (proxy) server receives valid credentials that are inadequate to access a given resource, the server should respond with the 403 Forbidden status code. Unlike 401 Unauthorized or 407 Proxy Authentication Required, authentication is impossible for this user and browsers will not propose a new attempt.
In all cases, the server may prefer returning a 404 Not Found status code, to hide the existence of the page to a user without adequate privileges or not correctly authenticated.
Besides that, I'm quite sure that an actual successful attempt will result in status code 200.
Expected HTTP 401 (Unauthorized), but got HTTP 405 from shop-redact. Your app's HTTPS webhook endpoints must validate the HMAC digest of each request, and return an
HTTP 401 (Unauthorized)
response when rejecting a request that has an invalid digest.
Screenshot
I have used osiset/laravel-shopify package
I have solved this error. Even though one app has been approved, the other app has the same solution in front of it, I still get this error from Shopify in the other app.
First I tried this solution in which the app was rejected. But I applied the same solution in the first app, which was approved
Route::get('/shop-redact',[AbcController::class,'shopRedact'])->middleware('auth.webhook')->name('shop.redact');
And then I tried to create a job for all GDPR webhook but the app was rejected
https://github.com/osiset/laravel-shopify/wiki/GDPR
What is the other solution to this?
Shopify webhooks make POST request to your endpoint so set post request
Route::post('/shop-redact',[AbcController::class,'shopRedact'])->middleware('auth.webhook')->name('shop.redact');
i've been facing a problem lately and i don't know how to handle it, or even what the problem might be coming from.
Tools:
-MYSQL(for data base)
-JAVA EE web application(to service as back-end)
-Jersey 2.26 dependency (to service as API on top of web application /CORS filter implemented)
-Apache Tomcat/7.0.69 ( as web server where web app sets )
-Angular 4 ( as website and client to the API)
-CentOS Linux release 7.3 (Core) (Server operating system )
Problem:
once the request is sent to the API ( to a specific secured Endpoint ) lets call it customers, Sometimes the response is 401 Unauthorized, and in other times it works just fine, from the angular website for instance, if press f12 and follow the requests, i send the same request again ( for the one i got 401 for ) but this time it works, the JWT is valid and it works just fine, and its not that there is too many request going to the server, even if its few sometimes i get 401, but most of the time it works great.
the only thing in the code that can return 401 is the authentication filter, which checks the validity of token, but it looks fine to me.
i checked this article that talks about 401 response, but still, its hard for me to grasp the idea why it works good sometimes and not work other times for the same request. i get the 401 while checking with the website and also with checking with postman. so i guess it's not a cache or cookies thing, but i might be wrong to assume this.
any ideas on what might be wrong ? or where should i be checking for bugs or errors ?
Thanks allot
Set tomcat security to false .
Im pretty new to webservice etc and I need figure out what is causing a http 403 response code.
I am hitting a service that was recently secured using siteminder, what I need to find out is what siteminder expects when receiving a http get request. Is there anyway I can find this out I assume that it is authenticating correctly due to the 403.
Im thinking that the request maybe missing some headers or indeed cookies I'm just finding it hard figuring out what is needed and would be great if I can get some guidance into how to at least find out what is expected.
I can hit the service fine through the browser.
T.I.A
You should turn on tracing on the web agent, check the log and see what headers are being sent, and if the 403 is coming from SiteMinder or your web service
I'm writing a REST-ish API service the provides the ability to interact with the end user's data in other 3rd party services (themselves REST APIs) via OAuth. A common example might be publishing data from my service to a third-party service such as Facebook or Twitter.
Suppose, for example, I perform an OAuth dance with the end user and Facebook, resulting in some short-term access token that my service can use to interact with the user's Facebook account. If that access token expires and the user attempts to use my service to publish to Facebook, what sort of error do I return to the user?
401 doesn't seem quite right to me; it seems that 401 would apply to the user's auth state with MY service. 403 seems much more appropriate, but also quite generic.
401 is the way to go. Two excerpts from the RFC2616 which defines the HTTP protocol:
Section 10.4.2 (about 401):
If the request already included Authorization credentials, then the 401
response indicates that authorization has been refused for those
credentials.
This seems to be appropriate for expired tokens. There are authentication credentials, but they're refused, so the user agent must re-authenticate.
Section 10.4.4 (about 403):
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
This should be used when the resource can't be accessed despite the user credentials. Could be a website/API that works only on US being hit by a asian IP or a webpage that has been declared harmful and was deactivated (so the content WAS found, but the server is denying serving it).
On OAuth2, the recommended workflow depends on how the token is being passed. If passed by the Authorization header, the server may return a 401. When passed via query string parameter, the most appropriate response is a 400 Bad Request (unfortunately, the most generic one HTTP has). This is defined by section 5.2 of the OAuth2 spec https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26
There's nothing wrong with being generic, and it sounds like a 403 status would be relevant - there is nothing stopping you from providing a more human readable version that elaborates in a bit more detail why.
I think the following is a comprehensive list if you have some level of ambition when it comes to error responses.
400 Bad Request
For requests that are malformed, for example if a parameter requires an int between 0-9 and 11 has been sent. You can return this, and in the response body specify parameter x requires a value between 0 and 9
401 Unauthorized
Used only for authorization issues. The signature may be wrong, the nonce may have been used before, the timestamp that was sent is not within an acceptable time window, again, use the response body to specify more exactly why you respond with this. For the sake of clarify use this only for OAuth related errors.
403 Forbidden
Expressly to signify that an operation that is well formed, and authorized, is not possible at all (either right now, or ever). Take for example if a resource has been locked for editing by another user: use the response body to say something along the lines of Another person is editing this right now, you'll have to wait mmkay?.
403 Forbidden can also have to do with trying to reach resources. Say for example that a user has access to a resource /resource/101212/properties.json but not to /resource/999/properties.json, then you can simply state: Forbidden due to access rights in the response body.
404 Not Found
The requested resource does not exist. Or the URL simply does not successfully map to an API in your service. Specify in response body.
405 Method Not Allowed
This is to represent that the API can not be called with for example GET but another method must be used. When this is returned also you MUST return the extra response header Allow: POST, PUT, etc.