I have a restAPI which allows for users to submit data to be saved in my database. When data is submitted their userID will be grabbed from the request header and added to the document
In my collection (mongoDB) there is the normal _id field and a userID field, which references the user.
My question is in the scenario that a malicious user submits a PUT or DELETE request to a document that does not belong to them what is the best way to handle it.
I pull the prediction from the DB just using the submitted _id, check the userID field against the requesting userID and issue a 403 response if they do not match.
I query the database by both _id and userID, so it would not be found if the document does not belong to the requesting user. I would then issue a 404 response just as if they had submitted an id that does not exist.
Both choices achieve the same goal, which is to prevent a user from editing or deleting a resource that does not belong to them, but which is "better"?
404 is for "not found", which is clearly not the case.
Use 403.
Quoting from Wikipedia:
HTTP 403 is returned when the client is not permitted access to the resource despite providing authentication ...
I would return 403 if user A has permission to view a resource that belongs to user B (as they are already aware of the existence of this resource). Otherwise, I would return 404 for privacy reasons. This is in line with the RFC 9110 standard:
An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
Related
I am trying to get access token from api https://api.amazon.com/auth/o2/token
POST /auth/o2/token HTTP/l.l
Host: api.amazon.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=refresh_token
&refresh_token=Aztr|...
&client_id=foodev
&client_secret=Y76SDl2F
But after POST request I get 500 server error.
Is it because my app is in draft status? or I am missing something while making request?
If it because of draft status then when the status will get change? any thoughts on this.
Thank you for your help in advance.
The documentation is wrong. I was getting the same exact error and came across this comment on a github issue which mentioned that the data has to be passed into the body of the request, not as query string parameters. Sure enough, this worked for me and I was able to get an access token. So just to clarify: grant_type, refresh_token, client_id, and client_secret should be passed into the body of the POST request to https://api.amazon.com/auth/o2/token and NOT as query string parameters.
Draft status will not keep you from requesting and receiving the access token.
Here are a few things to check as not much can be derived from the example post request from the documentation:
Did you configure AWS IAM role / policy / user properly
Did you use the correct IAM ARN when registering the application
Are you using the correct LWA credentials (I am assuming you're not passing foodev and Y76SDl2F as those are example parameters)
Have you self authorized the application (are you using the refresh token generated
for the authorized application)
Are you 'assuming the role' before the token exchange -- this is a very important step
and is very different in comparison to how access was handled with MWS -- if
you have not, the server will reject the token exchange regardless if the refresh
token is correct. More on that here
This is a non-exhaustive list, just some common issues I have seen other developers have with getting the access token during development, if these don't work you'll need to work with support as they can see the requests hitting the token endpoint.
I'm currently developing an App using Microsoft LIVE 2.0 API
Currently, I’m using these URLs as my authentication endpoints:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
However, when I sent the request to the token endpoint with the redirect URL as
https://blabla.com/accept_token.php?api_ver=wave5&csrf=AY7F6O4hF0n8yW3i2O_y6N-ky7zzfULiYV_fttLK1S3JgaeQz2GTk9FOeIGBBH5CvkfkEYCyPOCQCujcrij4KDy2wAMZyXqx24jvwZRtzOv0s9ADGYl1iFtvYtkmgeFmZEY&appdata=%7B%22use_case%22%3A1%2C%22type%22%3A1%2C%22flow%22%3A2%2C%22domain_id%22%3A12%2C%22tracked_params%22%3A%22%5B%5D%22%7D
I got errors saying the reply address does not match the reply addresses configured for the application
For the application, I set the reply address to be https://blabla.com/accept_token.php.
Is it possible that I add some parameters to the url and still make it match?
I'm pretty sure the reply url you send must match exactly the reply url registered on the application, including any query strings.
If there is variable state informaiton you need passed throughout the authentication process, you should use the state variable.
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-code
state
A value included in the request that will also be returned in the token response. It can be a string of any content that you wish. A randomly generated unique value is typically used for preventing cross-site request forgery attacks. The state is also used to encode information about the user's state in the app before the authentication request occurred, such as the page or view they were on.
I am trying to integrate Salesforce and Docusign. I'd like to send Create documents through a soap / rest call, and surpress the notification to the recipient. From Salesforce I'd like to send out the link to the envelope / documents through a branded email.
Is that possible? It seems like DS only supports a createAndSend call.
This documentation says I can create an envelope in draft form - https://docs.docusign.com/esign/restapi/Envelopes/Envelopes/create/ . It also says I get an envelope summary as a response.
https://docs.docusign.com/esign/restapi/Envelopes/Envelopes/create/#/definitions/envelopeSummary
As others have noted, Embedded Signing is the answer here. I've just done this with a client.
You would build the envelope with the SOAP API (good receipies from DocuSign on how to do this with APEX here: https://www.docusign.com/developer-center/recipes/docusign-for-salesforce).
When you define the Recipient, you would provide the ClientUserId in a CaptiveInfo object (use the ContactId for this). This tells DocuSign to skip sending the recipient an email, and you will handle this yourself.
Create and send the envelope (you can use templates as well).
You will need a portal or public Force.com site to move forward. The reason being that the URL for signing is a one-time-use link, and it expires 5 mins after it's generated. So you can't store it or send it in an email. By the time they click the link it will be dead.
So instead, you link to a Visualforce page you control. Add the ContactId to the URL as a parameter, so you know who is looking at the page.
When they load the page, you should have the Visualforce controller lookup the EnvelopeId (so if the page is about an Opportunity, you should store the EnvelopeId on the Opp or somewhere handy) and the recipient (use the ContactId to get the info about the recipient).
You then send this to DocuSign with the RequestRecipientToken method. It will return the token URL, and you can present it to the user.
I get JSON response {"errorCode": "USER_DOES_NOT_BELONG_TO_SPECIFIED_ACCOUNT", "message": "The specified User is not a member of the specified Account."} when we deployed application on a new SF sandbox with a different DocuSign account. Obviously I have changed the user/password and integration key for the new account. And after I make token request I get access token back, but I can not make post request due to above.
Can you guys help me understand why is this?
Users who want to send documents need a DocuSign account. It sounds like you've changed the username and password credentials however it is still pointing to the previous account hence the error. To resolve you need to update the integration to point to the new account.
My web application uses ajax and i check request is ajax request or not via php codes. If not then i generate 404 error otherwise run php codes that associated ajax function.
If user or search spider tries to reach ajax function page(ex: /books/ajax/books_list) web app return 404 not found status code and i see a lot of 404 errors in google webmaster tools.
I should change 404 status code but which one is right for this condition ? Can be "406 not acceptable" ?
I think 403 (Forbidden) probably best describes it. The resource is there, but you've determined that you're not going to give access to that resource, and even authenticating the user isn't going to help.
I would suggest that you return the 406 you suggested. The only alternatives worth considering are '501 not implemented'
The server does not support the functionality required to fulfill the request.
This is the appropriate response when the server does not recognize the request
method and is not capable of supporting it for any resource
And '403 Forbidden'
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe
the reason for the refusal in the entity. If the server does not
wish to make this information available to the client, the status
code 404 (Not Found) can be used instead.
Not sure how you determine whether it's a proper Ajax request. If you expect it to be POST, but the spider uses GET, then it should be 405 (Method Not Allowed).
You should not be using 406: it means "not acceptable", in the sense that you cannot support the HTTP Accept: headers that the browser sent. This would likely be incorrect (as you likely aren't checking the Accept headers at all).
If you really reject the request because it comes from an unauthorized client, then 403 is appropriate.
It's my understanding that SE spiders get a little skittish if they see errors that indicate server problems. (A 406 can indicate a badly implemented server.) A 404 doesn't describe what you're looking for, as the resource is there, but a 403 (forbidden) just lets the spider know that this page isn't for them. You can also use your robots.txt file.