I have a bot, all the functionality works (Can send messages, read, issue roles). But if I want to change its own status (or read personal settings), then I immediately get an error 403 forbidden.
Related
Is it possible to check Http status code in Apache configuration as %{REQUEST_STATUS} for instance?
There is no such thing as a "request status", and no way for a server to interact with a browser in the middle of serving an error message.
HTTP is not an interactive protocol; the browser sends a request, the server sends a response, and that's it. So if the browser sends a request, and the application crashes, the server can send a response with 500 and the error details, or a response with 401 requesting the user to log in. Either way, that's the end of the conversation.
When it receives a 401 response, the browser can't say "here's the login details, carry on with the current request", it has to make a new request. It can make an identical request, which might reproduce the error message; but the original error message is gone.
If the requirement is to show a different amount of detail to different users, you need some notion of optional authentication, so that the server can decide immediately whether to include the error details or not, without an extra round-trip to the browser. I would suggest either:
Have a list of IP addresses which the application can check against; if the IP address of the request is in the list, include the error details.
Have a custom login system where you can authenticate and set a "session cookie" in the browser. If the user has an active session cookie, include the error details.
I tried to get a list of users through the API, but in response I got:
Missing Access 403 Forbidden (error code: 50001)
Request: https://discord.com/api/v9/guilds/{guild.id}/members;
And I was thrown out of my account, asking to verify my account.
At the same time, I accessed the server from the account that owns the server ...
MB is the fact that this is not a bot, but a live account?
Answer from comment:
Yes, using HTTP requests with user Discord accounts (user-botting) is
against Discord TOS and they can eventually terminate your account.
Create and use a bot account instead.
I am trying to click on Search button after entering data in some fields which has to show the results(list of flight available from city A to city B on t he selected date) according to the search in the same page.
When I run the Selenium - Java script for this scenario system is showing HTTP ERROR 403, while it works fine when I do it manually.
403 Forbidden
The HTTP 403 Forbidden client error status response code indicates that the server understood the request but refuses to authorize it.
This status is similar to 401, but in this case, re-authenticating will make no difference. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.
Status
403 Forbidden
Example response
HTTP/1.1 403 Forbidden
Date: Wed, 28 May 2019 07:28:00 GMT
Reason
You code trials and the error trace log would have helped us to debug the issue in a better way. Possibly the WebDriver controlled Browser Client is getting detected and hence the subsequent requests are getting blocked.
Outro
You can find similar discussions in:
Failed to load resource: the server responded with a status of 429 (Too Many Requests) and 404 (Not Found) with ChromeDriver Chrome through Selenium
Unable to use Selenium to automate Chase site login
I have an application that uses OAuth 2 to access Gmail. This is working fine for most users. For some users, however, my application fails at the point of trying to read the Gmail labels, with http error 403 (forbidden). Keep in mind that previous to this API call, I have accessed the user profile successfully. Here is the call that fails:
GET /gmail/v1/users/user.name#domain.com/labels?access_token=ya29.fwI_zL1rF3xOIQcHNzpBhmjVlJhRpofkh4a9mVvwhYRo6H09qX5RNKv76zKT7e6-sEZr
I am requesting the following scopes when getting the access token, and the user has logged in to Google and accepted the request for access (and I can see this when we look at his security dashboard):
https://www.googleapis.com/auth/calendar
https://www.googleapis.com/auth/userinfo.profile
https://www.google.com/m8/feeds
https://www.googleapis.com/auth/tasks
https://www.googleapis.com/auth/gmail.labels
https://mail.google.com/
Note that I just added the gmail.labels scope in at attempt to fix this.
Again, this code is working fine for most users - why do some users fail the label request?
Use the shorthand value me instead of user.name#domain.com and the user who the access token belongs to will be used automatically.
I'm designing a RESTful API that is using the HTTP status codes and verbs as key components in communicating.
On the religious level it's on the zealot side of RESTafarian.
Rule of thumb for deciding HTTP status codes has been this graph, or similar resources.
GET /api/documents/1 - 401 User has not logged in
GET /api/documents/1 - 200 User has permission
GET /api/documents/1 - 403 User does not have permission
DELETE /api/documents/1 - 204 Users has permission
DELETE /api/documents/1 - 403 User does not have permission
GET /api/documents/2 - 404 Users permission irrelevant, resource does not exist
DELETE /api/documents/2 - 404 Users permission irrelevant, resource does not exist
DELETE /api/documents/1 - 404 Users has permission, resource already deleted
DELETE /api/documents/1 - 404 Users does not have permission, resource already deleted
Goals:
Consistency in usage
Not to expose private information through errors
Proper use of status codes for client or middle layer caches
Fail early, keep lookups to a minimum
In this situation there is a lot of different status code to chose from ( 404, 403, 410, 405) and in my case I went with 403 on a existing resource if its not yours to not clear the cache, and 404 on all non existing resources so to tell the clients to wipe that data.
But I do not like the switch from 403 to 404 on resources that are not yours.
I'm interested to hear from others how you solved this use-case, or in general what status codes you feel appropriate to send in all invalid DELETE calls, since I deem that as one of the hardest to be concise with.
(A lot of REST discussions and answers on the internet in it whole are just "Throw a 400 bad request, no one cares anyway", I do not have a problem that needs a quick fix or a pragmatic hack. Thanks)
General pointer: In case a resource exists but a user is not authorized to perform operations on it, you should return 401 over 403:
401 Unauthorized
Similar to 403 Forbidden, but specifically for use
when authentication is required and has failed or has not yet been
provided.
and
403 Forbidden
The request was a valid request, but the server is refusing to respond to it. Unlike a 401 Unauthorized response, authenticating will make no difference.
See also Correct HTTP status code when resource is available but not accessible because of permissions
I went with 403 on a existing resource if its not yours to not clear
the cache, and 404 on all non existing resources so to tell the
clients to wipe that data.
As pointed out earlier, 401 should be used instead of 403. 404 is ok to return if you just want to say "sorry, resource not found". If you however want to say "resource was here but it's not anymore and never again will be" (this appears to be the case in your situation) you can return 410:
410 Gone
Indicates that the resource requested is no longer available
and will not be available again. This should be used when a
resource has been intentionally removed and the resource should be
purged. Upon receiving a 410 status code, the client should not
request the resource again in the future. Clients such as search
engines should remove the resource from their indices
To summarize, this is how I would implement it in your case. The changes I made are in bold.
GET /api/documents/1 - 401 User has not logged in
GET /api/documents/1 - 200 User has permission
GET /api/documents/1 - 401 User does not have permission
DELETE /api/documents/1 - 204 User has permission
DELETE /api/documents/1 - 403 User does not have permission
GET /api/documents/2 - 404 Users permission irrelevant, resource does not exist
DELETE /api/documents/2 - 404 Users permission irrelevant, resource does not exist
DELETE /api/documents/1 - 410 User has permission, resource already deleted
DELETE /api/documents/1 - 401 User does not have permission, resource already deleted
For the last one, you can return 401 if you do not want the unauthorized user to know that there was a resource that has already been deleted. If you don't care you can return 410. That is for you to decide.
I do not like the switch from 403 to 404 on resources that are not yours.
It's perfectly fine to return different status codes depending on what the situation is.
I hope this helps you out a bit.
The response code for an invalid delete call depends on what the failure is. In your cases, I would go with:
DELETE /api/documents/1 - Users has permission
204 No Content
DELETE /api/documents/2 - Users permission irrelevant, resource does not exist
404 Not Found
DELETE /api/documents/1 - Users has permission, resource already deleted
410 Gone
DELETE /api/documents/1 - Users does not have permission, resource already deleted
403 Forbidden
The last call is the only one worth really talking about. I believe (and your graph agrees) that the user's lack of permission takes precedence over the resource already being deleted. If the user were to get a 410, then you'd be leaking information (resource already deleted).
As far as 401/403, 401 is "you haven't logged in yet". 403 is "you have logged in, and you don't have permission to do what you want". I don't see anything unusual in your usage of those codes.
Having said all this, I feel like I'm somehow misinterpreting the question.
I don't like the idea of a 404 as representing a failed delete where the resource cannot be found (or for a put or patch for that matter). It is fairly common to have DNS issues and for people to have parameter based routing issues that would both yield a 404 if the actual site could not be found. Introducing this type of ambiguity can make diagnosing simple problems really and unnecessarily difficult. I think 410 Gone is a better choice for representing a resource not found when it comes to APIs.