I work on a number of Rails sites with forms and take advantage of Rails built-in authenticity token support. Works like a charm. Happy Happy Joy Joy.
It varies, but I would say I average about a SQL injection attack once a month that is successfully caught as having a failed authenticity token check. Wonderful.
The problem is the failed authenticity token check generates an ActionController::InvalidAuthenticityToken exception which returns an HTTP 5xx error because it is an unhandled exception. Good: the bad request is not allowed. Bad: The hacker is functionally informed that my server crashed which is hacker-code for KEEP ATTACKING THIS INTERFACE AT ALL COSTS because they aren't catching this error.
So what is the best way to handle this? If I simply try to wrap my controller method in a try/except, it doesn't even get to my method. It seems that if I want to respond with an access denied or some similar "bad user input" error (HTTP 4xx) then I would have to plug into the pipeline which seems like overkill for something the entire world has to deal with.
Also, what is the proper HTTP response? 400 (Bad Request)? Seems correct, but the other common scenario that generates this error is when a user pulls up your form from cache after the access token has timed out. In this case, the best user experience would be to simply refresh the form with a message saying it took too long for them to fill out the form or something like that. I suppose that could be in the body of an HTTP 400 response.
So how do I build this? Maybe something in the ApplicationController? Why isn't this the default? Maybe it is being handled properly and my "Unhandled Exception" reports are earlier in the pipeline?
Related
I am developing a REST API in Rails.
The API returns an HTTP 422 unprocessable entity with error messages when model validations fail.
However, a model can have several validations and I want to delegate the translation of the error messages to the API consumer and that is why it needs to differentiate what was the specific cause for the server to return a 422.
I was thinking about using subcodes, just like Facebook does in its API. Is there a way to do this keeping the REST practices?
Also, what does one do when an error 422 occurs for multiple causes at the same time?
RFC 7231
Client Error 4.x.x
Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
Normally, you should encode information that is specific to your domain in the message-body of the response. The status line and response headers are there for generic components (browsers, caches, proxies) to have a coarse understanding of what is going on.
The Problem Details specification lays out the concern rather well.
consider a response that indicates that the client's account doesn't have enough credit. The 403 Forbidden status code might be deemed most appropriate to use, as it will inform HTTP generic software (such as client libraries, caches, and proxies) of the general semantics of the response.
However, that doesn't give the API client enough information about why the request was forbidden, the applicable account balance, or how to correct the problem. If these details are included in the response body in a machine-readable format, the client can treat it appropriately; for example, triggering a transfer of more credit into the account.
I don't promise that Problem Details is well suited for your purposes; but as prior art it should help you to recognize that the information you want to communicate belongs in the body of the response, with a suitable Content-Type header to inform the consumers which processing logic they need to use.
I am getting the HTTP 401 error for the file download URL generated by GET /users/{userId}/drive/items/{item-id}/content, which claims it doesn't require the authentication information.
This seems to happen if the prior request for file item information received 401 error and we refreshed the token, but not sure. Anyway, this always happens anyway from one of my customers' site, not happening frequently though.
Most of all, I'd like to know what's the best approach for the critical fix for my customer, and what's the real cause and solution.
Thanks.
I have a web application which i need to be load tested using LoadRunner. When I record the website using vugen it works good and there is no any application bug. But when I tried to replay the script, script failed after login and while navigating to next page, say, Transaction. At the end of log, I receive error:
Action.c(252): Error -26612: HTTP Status-Code=500 (Internal Server Error)
for "http://rob.com/common/transaction
Please help me to resolve this error.
LoadRunner generates HTTP request just as your browser does, this error is the same error you would get if you would go to that URL using your browser. Error code 500 is a generic server error that is returned when there is no better (more specific error to return).
Most likely the login process requires some form of authentication which is protected against a replay attack by using some form of token. It is up to you to capture this token using Correlations in LoadRunner and replay it as the server expects. The Correlation Studio in VuGen should detect and identify the token for you but since authentication methods vary it is sometimes impossible to do this automatically and you will have to create manual correlation. Please consult the product documentation for more details on how to do it. If your website is publicly available online then post its URL and I will try to record the script on my machine.
Thanks,
Boris.
Most common reasons
You are not checking each request for a valid result being returned and using a 200 HTTP status as an assumed correct step without examining the content of what is being returned. As a result when data being returned is incorrect you are not branching the code to handle the exception. Go one to two steps beyond where your business process has come off the rails with an assumptive success and you will have a 500 status message for an out of context action occurring 100% of the time.
Missed dynamic element. Record three times. Compare the code. Address the changing components.
A form is submitted using jQuery form plug-in to an action in MVC framework. In the action, if form validation fails a reply should be sent back to the client. jQuery form plug-in comes with error and success callbacks (like any other jQuery Ajax functions).
Isnt it a better practice to return an HTTP Exception with error-code 400 (Bad Request) and catch it in error callback rather than returning a successful HTTP response and catching it in success callback?
If the answer is yes, wouldn't it be more descriptive to have data attached to HTTP Exception?
From what I see right now, HTTPException.Data is readonly. One of the constructors seems to do the job (HttpException(SerializationInfo, StreamingContext)) but I cant wrap my head around it.
Would someone please explain for me how to add data to HTTP Exception?
No, it's not better practice to simply return an error code, even if you do manage to attach messages to the HTTPException.
Why? Well, you lose so much information that way. You have the option to return an arbitrary JSON object, which could include (for example) a list of all validation errors (or indeed, any pertinent info which may help the calling client out), which you then render on the client so that the user is able to correct.
Also, you've got to consider what happens when your call is successful. Is a 200 return code really enough for your purposes?
I'm writing an actionscript library for an api. I use a URLLoader object to load data from the api. The problem I'm having is that whenever the api returns an http status in the 400s, actionscript treats this as an io error. This is all find and good, however, it seems like there is no way to access any data that was returned if this is the case. Consequently, any helpful xml about the cause of the error that gets returned is lost. Is there any way around this? It makes the library kind of a pain, if there can't be any useful information for developers when the api returns an error. Thanks for any help!
You can't get access to the data in an event of a 400. You can get the status code, however, by adding a listener for the HTTP status event.
If you control the back-end code, there are a couple of workarounds:
One option is to have the backend respond with 200s even in error cases when talking to a flash client, but with a special error code so the client knows that the 200 response is actually an error.
Another option is to set a cookie on the client containing the error message. Flash can't natively access cookies, but you can call out to javascript using ExternalInterface to read the cookie, or optionally the client can do another hit to a special back-end controller that reads the cookie and responds with an error message.