I'm currently developing a little algorithm to solve the VRP. I herefore use the HERE Matrix Routing API to identify the actual travel times. I just came across the issue, that the retrieved status url after submitting the matrix seems to not accept the API key authorization. Here a little exapmle:
After submitting my matrix, I try to access the status of my calculation via the status url as described in the documentation:
https://matrix.router.hereapi.com/v8/matrix/{matrixId}/status?apiKey={apiKey}
as well as with the returned status url after submitting the request (which is basically the above URL prefilled and with resolved forwarding):
https://aws-eu-west-1.matrix.router.hereapi.com/v8/matrix/{matrixId}/status?apiKey={apiKey}
From my understanding and the way how it's documented, I expect this to be working. Instead, I'm receiving an error code 401, Unauthorized: No credentials found
My request succeeds, when I'm deleting the /status after the matrixId. Is this the expected behaviour or did I reveal a little bug?
Thanks for your help!
BR, Difreg
This is unfortunately due to a combination of how the service operates, and how some client libraries are configured to automatically follow HTTP redirects, like Python requests.
I answered a similar question a few days ago, and you can see the answer here.
Hopefully that helps you figure it out, but if it doesn't, feel free to ask again here.
Related
i already tried to find an answer here on nearly at any place at the web, but didn't find an answer that helped me out here - so i'm trying it here with this question:
i have to to get some information from a server in a domain, using https via indy components and the windows authentication. that's working quite fine (via IdHTTP1.Get(sURI)), the server logs are showing this (domain/user/request) and the response is always valid.
afterwards i try to post now some new values to the requested data, but this fails, since i get a "401" authenticaion error. BasicAuthentication=false, and HTTPOptions=[hoInProcessAuth,hoForceEncodeParams] via IdHTTP1.Post(sURI, Req_Json), where Req_Json is a UTF-8 encoded TStringStream. Now (and only when trying to POST) the IdHTTP1Authorization event is triggered twice, even if I do a handled=true there (read somewhere in a forum) it fails, if I do nothing there I get the same result: 401. There were some tips about the IdHTTP1SelectAuthorization event, but with that I had no luck, too.
Any ideas, where to start to get this solved? If there are any questions open, don't hesitate to ask!
p.s.: trying to post the same information via postman works correctly - so i guess it's about delphi/indy ...
The same thing seems to have happened two years ago public-profile-url causing error, but the approved solution on that question is not solving this problem.
Any connections requests requesting the field 'public-profile-url' throws the following error:
https://api.linkedin.com/v1/people/~/connections:(public-profile-url)?start=0&oauth2_access_token=<token>
<error>
<status>500</status>
<timestamp>1491329264595</timestamp>
<request-id>8IJSBKJHQR</request-id>
<error-code>0</error-code>
<message>Internal API server error</message>
</error>
If this is just an issue with their API, I'd love to get LinkedIn's attention on the matter.
Edit: Interestingly, I found a specific Linkedin connection that is causing the failure (by adjusting the 'start' and 'count' args). It's probably not wise to post that here, but I can provide that information to LinkedIn staff, if need be.
Edit 2: I found replacing 'public-profile' with 'site-standard-profile-request' does function as a workaround. It's not exactly the same thing, but close enough if your user is already using oauth
Same problem, in my case solved removing the "site-standard-profile-request" and the "current-share" attributes from the linkedin v1 people request.
Here is the working api url:
https://api.linkedin.com/v1/people/~:(id,first-name,last-name,maiden-name,formatted-name,phonetic-first-name,phonetic-last-name,formatted-phonetic-name,headline,location,industry,num-connections,num-connections-capped,summary,specialties,positions,picture-url,picture-urls::(original),site-standard-profile-request,api-standard-profile-request)
I m creating a code in which based on query string the URL is changing when no values are supplied in URL everything is working fine but as i supply values to URL it shows Error HTTP Error 403.0 - ModSecurity Action
Kindly suggest some solution
also the same is working fine in local problem occurs when i upload my webpage to server
I know this is an old thread, but posting the answer so that it can be helpful for others. ModSecurity is an open source, cross-platform web application firewall (WAF) module.
https://modsecurity.org/about.html
So whenever you see the 403 (ModSecurity Action), this means that the mod security firewall has blocked the request. The probable cause could be vulnerable data present in the posted data, or the it could be because of the URL posted as parameter or it could be JavaScript.
In above case, the ModSecurity might have deemed the input as SQL Injection attack and hence may have blocked it. If you look into the logs of the firewall it may give you the detailed explanation.
In my case, I was passing URL as query parameter in the request hence it was returning 403.
When requesting some pages with the following code:
HttpDialog(httpClient, IDN.toASCII(domain)).send(HttpRequest(uri = "/")).end
spray-can client returns responses with redirects to another URLs (e.g. 302 Found). Is there a standard way of telling spray to automatically follow redirects? And if not, what is the best way to implement this behavior myself with akka futures?
Update 2: The PR was merged and documentation for redirection following is spray-can can now be found here
Update: I decided to have a crack at implementing this and have sent a PR. Hopefully it will get merged.
There is no way to currently tell spray-can client to follow 3xx redirects. See this thread for more details.
There is an open ticket, so hopefully this will happen in the future. I'm sure a contribution would be welcomed.
I have a REST endpoint accepting a POST request to mark a code as redeemed. The code can only be redeemed between certain dates.
How should I respond if someone attempts to redeem the code early?
I suspect HTTP 403, Forbidden, is the right choice but then the w3c states that "the request SHOULD NOT be repeated" whereas in this case I would anticipate the request being repeated, just at a later date.
409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict and
resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that might not be
possible and is not required.
403 Forbidden makes more sense if they are trying to redeem a coupon that has already been redeemed, though 410 Gone seams elegant in this situation as well.
404 Not Found isn't ideal because the resource does in fact exist, however you can use it if you don't want to specify a reason with the 403 or if you want to hide the existence of the resource for security reasons.
If you are using HATEOAS, then you can also head you clients off at the pass (so to speak) by only including a redeem hypermedia control in the coupon resource (retrieved via a GET) when the coupon can be redeemed; though this won't stop overly bound clients from trying to redeem it anyway.
EDIT: Thanks to some good critiques (see below), I want to caveat this answer. It is based on Richardson & Ruby's writeup, which arguably doesn't mesh well with the httpbis writing on 403 Forbidden. (Personally, now I'm learning towards 409 as explained by Tom in a separate answer.)
403 Forbidden is the best choice. I will cite RESTful Web Services by Richardson & Ruby line by line. As you will see, 403 is a great fit:
The client's request is formed correctly, but the server doesn't want to carry it out.
Check!
This is not merely the case of insufficient credentials: that would be a 401 ("Unauthorized"). This is more like a resource that is only accessible at certain times, or from certain IP addresses.
Check!
A response of 403 implies that the client requested a resource that really exists. As with with 401 ("Unauthorized"), if the server doesn't want to give out even this information, it can lie and send a 404 ("Not Found") instead.
You wrote above: "The Code representation is available to be GETted before it goes live." So, you aren't trying to hide anything. So, stick with the 403. Check!
If the client's request is well-formed, why is this status code in the 4xx series (client-side error) instead of the 5xx series (server-side error)? Because the serve made it decision based on some aspect of the request other than its form; say, the time of day the request was made.
Check! The client's request was formed corrected, but it was inappropriate for the particular time.
We went four for four. The 403 code is a winner. No other codes match as well.
All of this said, a plain, non-specific 400 wouldn't be wrong, but would not be as specific or useful.
Another answer suggested the 409 Conflict code. Although worth considering, it isn't as good a fit. Here is why. According to Richardson & Ruby again:
Getting this [409] response response means that you tried to put the server's resources into an impossible or inconsistent state. Amazon S3 gives this response code when you try to delete a bucket that is not empty.
Claiming a promotion before it is 'active' wouldn't "put a server resource into an inconsistent state." It would break some business rules -- and result in cheating -- but it wouldn't cause a logical contradiction that I see.
So, whether you realized it at the onset of asking your question or not, 403 is a great choice. :)
Since Rest URLs should represent resources I would reply with 404 - Not Found
The resource is only available between certain dates, so on any other date it is not found.
When it says the request "SHOULD NOT be repeated", it is referring to the message that you should send to the viewer.
It has nothing to do with whether an actual request is repeated. (The user will get the same 403 message over and over again if s/he so desires.)
That said, a 404 is not appropriate for this because the resource is available - just that the code is not redeemable/forbidden to redeem. It is actually harmful because it tells the user that you probably made a mistake in your URL link or server configuration.
Of course, this assumes that on the appropriate date you return a 200 instead.