Am doing some system testing to URL Sanitation. So I tried rushing the APIs with junk data.Example
http://ipaddress/AppContext/api1?query=%S%n%n%s
If I call this API , my log throws an exception 'Invalid HEX character in escape sequence %n'
How to I catch this in tomcat level and throw a 400 bad request
You can't.
Tomcat doesn't decode the query string until the application requests one or more parameters. The best you can do is write a Filter that always tries to access the query string before the main request processing and returns a 400 response if an exception is thrown.
Related
I am getting my objects by calling
https://<bucket>.storage.googleapis.com/?prefix=folder%2F<object name>%2F&delimiter=/&max-keys=1000
I have tried with other special characters like !, #, #, $, ^, &, *, (, ), etc.
For the other special characters I just encode them in the , and I get the response just fine.
For example, with object "!#" under folder, the url is:
https://<bucket>.storage.googleapis.com/?prefix=folder%2F%21%22%2F&delimiter=/&max-keys=1000
However, when I try with object names with "%" and encode the percent sign to "%25", I get the following error:
<?xml version='1.0' encoding='UTF-8'?><Error><Code>InvalidSecurity</Code> <Message>The provided security credentials are not valid.</Message><Details>Request was not signed or contained a malformed signature</Details></Error>
What could be causing this issue ?
Edit
So I have tried double encoding the percent sign such that '%' character becomes "%2525" in the request. However, in the response, the prefix is strangely "%25". After testing with more cases, it turns out a request is successful only when "%25" is followed by 2 characters both within the range of '0' and 'f', however, the response prefix would be wrong. For example, "%25ab" in the request would result in "%ab" in the response prefix.
I believe this is a service side bug: see https://issuetracker.google.com/issues/117932947
I think a workaround is to encode the percent twice. But this may start failing in the future when the bug is fixed.
The error message you're seeing is because you don't have enough permissions to access to your object.
If you're using an authentication method (APIkey, bearer, etc) make sure that they have the needed Roles for GCS.
However, I can see that you're calling the objects just as a GET request. Try to Make your objects public and try it again with that encoding (%25). It should work.
Hope this is helpful!
I've built an interface to a thridparty Rest/Json web API, everything is working great with valid test cases, but when I request something invalid from the API, say a job that doesn't exist, the API returns a response where the body = 'null' and has a the content type as "application/json; charset=utf-8". I'm not sure if this is standard practice for a web API, but when I call Execute on the IHttpClient I end up with an Access Violation and the client exits.
Protrace is a follows
Exception code: C0000005 ACCESS_VIOLATION
Fault address: 00007FFC6733DAAD 01:000000000077CAAD C:\Apps\Progress\117\bin\prow.dll
** ABL Stack Trace **
--> Write OpenEdge.Net.HTTP.Filter.Payload.JsonEntityWriter at line 463 (OpenEdge/Net/HTTP/Filter/Payload/JsonEntityWriter.r)
ExtractEntity OpenEdge.Net.HTTP.Lib.ABLSockets.ABLSocketLibrary at line 360 (OpenEdge/Net/HTTP/Lib/ABLSockets/ABLSocketLibrary.r)
Execute OpenEdge.Net.HTTP.Lib.ABLSockets.ABLSocketLibrary at line 312 (OpenEdge/Net/HTTP/Lib/ABLSockets/ABLSocketLibrary.r)
Execute OpenEdge.Net.HTTP.HttpClient at line 154 (OpenEdge/Net/HTTP/HttpClient.r)
TryRest Tempo.TempoApi at line 1264 (D:\_Dev\OnTap-Trunk\rcode\Tempo\TempoApi.r)
ExecuteRest Tempo.TempoApi at line 234 (D:\_Dev\OnTap-Trunk\rcode\Tempo\TempoApi.r)
TryRest is:
METHOD PRIVATE INTEGER TryRest(
INPUT oUri AS URI,
INPUT cType AS CHARACTER,
INPUT cContentType AS CHARACTER,
INPUT oContent AS Object,
OUTPUT oResponse AS IHttpResponse ):
DEFINE VARIABLE result AS INTEGER NO-UNDO.
DEFINE VARIABLE oRequest AS IHttpRequest NO-UNDO.
CASE cType:
WHEN "GET" THEN
oRequest = RequestBuilder:GET(oURI)
:AddHeader("Authorization", "Bearer " + STRING(cAccessToken))
:AcceptJson()
:REQUEST.
END CASE.
oResponse = ResponseBuilder:Build():Response.
oClient:EXECUTE(oRequest,oResponse).
RETURN oResponse:StatusCode.
CATCH e AS Progress.Lang.Error:
UNDO, THROW e.
END CATCH.
END METHOD.
I'm using the latest OpenEdge client, 11.7.2 Windows x64.
My question is, is it normal for a web API to return 'Null' for an invalid request?
And secondly, this is obviously an unhandled exception in OpenEdge.Net.HTTP.Lib, which should not result in client crash.. Any ideas for working around it? I've tried changing AcceptJson() to AcceptAll, and AcceptHTML, but the protrace is the same, crashing in JsonEntityWriter.
Thanks
No, typically RESTful APIs will return a 404 if you make a request to a route that isn't valid. The only exception that I can think of off the top of my head is if you attempt to access a route that has parameters as part of the URI.
I have a sightly java class(a java class included inside component) which calls an api and checks whether the response in null. If its null, I have to call the error component. When I am setting the response status as 404, it is not working because before executing that line, it is taking the response as 200. How to call the error component in this case.
Note: I have tried redirecting the URL to error.html, but thats not the proper solution.
It is generally bad practice to redirect or change the response status from a component/view as the response might already have some content that was committed.
You might want to redesign you application to either:
Call the remote API at the beginning of the request handling and, if the remote API returns null, return a 404 before anything else is committed to the response.
Handle the null response from the remote API by either:
Rendering an appropriate response, in case the null response is expected/permitted in some cases.
Throwing an exception, which will result in status 500, in case the null response is not expected.
In my akka http app I receive a lot of errors like this one:
Illegal request-target: Invalid input 'v', expected HEXDIG (line 1, column 72)
It happens when I simply add a '%' character to the URL. In this case akka exoects a hex value.
Is it possible to somehow 'clean up' or encode/ignore such characters?
For users of an API who got this error message and don't know how to solve it:
I had the same problem, with a URL that queries something from a third party database, one part of the URL was simply not correct and that caused this error message.
I think this error message is misleading since it sounds like you should encode the URL differently which is not the case at all, just check if the structure of the URL is correct.
I'm writing a REST based web service, and I'm trying to figure out the best way to handle error conditions.
Currently the service is returning HTTP Errors, such as Bad Request, but how can I return extra information to give developers using the web service an idea what they're doing wrong?
For example: creating a user with a null username returns an error of Bad Request. How can I add that the error was caused by a null username parameter?
According to the HTTP spec, the text that comes after the three digit response code, the "Reason-Phrase", can only be replaced with a logical equivalent. So you can't respond with 400 null user and expect anything useful to happen. Indeed, The client is not required to examine or display the Reason- Phrase.
In general, the HTTP response entity (typically the page that accompanies the response) should contain information useful to the client to guide them forward, even when the response is an error. On the web, most such errors are HTML, and are devoid of machine readable information, but most browsers do show the error to the user (and SO's error page is pretty good!).
So for a primarily machine readable resource you have two options:
Pass a human readable message anyway. Return 400 Bad Request with a HTML response, which the client may opt to show to the user. It's dead easy but it's a bit like throwing an unchecked exception, it passes all the hard work to the client, or indeed the end user.
Allow clients to recover. Return 400 Bad Request with a machine readable response which is part of your API, so clients can recover from known error conditions. This is harder, like throwing a checked exception, it becomes part of the API, and it allows clients to recover gracefully if they want to.
You could even make the server support both scenarios by defining a media type for the machie readable error recovery document, and allow clients to "accept" them: Accept: application/atom+xml, application/my.proprietary.errors+json
Clients that forget the mandatory field can opt in to getting machine readable errors or human readable errors by choosing to Accepting the error media type.
It's stated in the HTTP spec that most error codes should return some basic text that gives a clarification of why the error is being returned. The basic Java Servlet Spec defines the HttpServletResponse.sendError(int Code, String message) for this purpose.
String desc = "my Description";
throw new WebApplicationException(Response.status(Status.BAD_REQUEST).entity(desc).type("text/plain").build());