I have a simple resource that provides a list of translations. The get end point takes a language and returns a dictionary of translations. Any updates are going to be on just one translation, so I figured that would be appropriate to do as a patch.
In my api controller, I can make a put work just fine, but any call I make to my patch end point is giving me a 403 forbidden error and I don't understand why.
[HttpGet]
// GET api/<controller>
public Dictionary<string,string> Get(String id)
{
return TranslationSvc.GetTranslatedStrings(id);
}
[HttpPatch]
public TranslationEntry Patch(TranslationEntry data)
{//403 prevents this end point from ever executing
if (TranslationSvc.UpdateTranslation(data.Lang, "", data.Translation.Key, data.Translation.Value))
{
return data;
}
else
{
//return a 500 error;
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}
[HttpPut]
public TranslationEntry Put(TranslationEntry data)
{//works, but technically a put should be the full resource which is the full collection
if (TranslationSvc.UpdateTranslation(data.Lang, "", data.Translation.Key, data.Translation.Value))
{
return data;
}
else
{
//return a 500 error;
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}
I found the problem. I had forgotten that I was running against a local proxy that simulated our single sign on behaviors. That local proxy was configured to deny anything but GET and post actions basically. Sorry for the false alarm question :)
Related
I am implementing payments for my website using the API of an external service (ie. the service of the payment provider).
Let's say the user clicks 'BUY', and then we go to my controller which says something along the lines of:
public function buyFunction() {
$result = $this->ExternalService->pay();
if ($result->success == true) {
return 'We are happy';
}
}
I have also created the aforementioned externalService which has the pay() method:
class ExternalService {
public function pay() {
response = //Do stuff with Guzzle to call the API to make the payment
return response;
}
}
Now, sometimes things go wrong.
Let's say the API returns an error - which means that it throws a GuzzleException - how do I handle that?
Ideally, if there is an error, I would like to log it and redirect the user to a page and tell him that something went wrong.
What I've tried
I have tried using a try/catch statement within the pay() function and using abort(500) but this doesn't allow me to redirect to the page I want to.
I have tried using a try/catch statement within the pay() function and using return redirect('/mypage') but this just returns a Redirect object to the controller, which then fails when it tries to call result->success
I have tried using number 2 but also adding a try/catch block to the controller method, but nothing changed.
In the end, I have found two solutions. In both, I use a try/catch block inside the pay() method. Then I either return 0; and check in the controller if (result == 0) or I use abort( redirect('/mypage') ); inside the try/catch block of the pay() method.
What is the right way to handle this?
How to use the try/catch blocks?
In my experience, avoid handling exceptions let them pass through and handle them accordingly with try catches. This is the most pragmatic approach. Alternatively you will end up checking result is correct in weird places, eg. if ($result) {...}. Just assume it went good, except if the exception is thrown. Bonus: never do Pokemon catches with Exception $e unless you specifically needs it!
class ExternalService {
public function pay() {
try {
response = $client->get(...);
} catch (BadResponseException $exception) {
Log::warning('This should not happen check payment api: ' . $exception->getMessage());
throw new PaymentException('Payment did not go through');
}
return response;
}
}
Assuming you have your own Exception.
class PaymentException extends HttpException
{
public function __construct(?\Exception $previous = null)
{
parent::__construct(Response::HTTP_BAD_REQUEST, 'Unexpected error processing the payment', $previous);
}
}
This enables you to handle the flow in a controller, where it would make sense to handle the redirect. Sometimes if the exception is very integral or common to the web app, it can also be handled by the exception handler instead.
class PaymentController {
public function pay(PaymentService $service) {
try {
$payment = $service->buyFunction();
} catch (PaymentException $exception) {
return redirect()->route('app.payment.error');
}
return view('app.payment.success', compact('payment'));
}
}
I have the following middleware code:
public class UoWMiddleware : OwinMiddleware
{
readonly IUoW uow;
public UoWMiddleware(OwinMiddleware next, IUoW uow) : base(next)
{
this.uow = uow;
}
public override async Task Invoke(IOwinContext context)
{
try
{
await Next.Invoke(context);
}
catch
{
uow.RollBack();
throw;
}
finally
{
if (uow.Status == Base.SharedDomain.UoWStatus.Running)
{
var response = context.Response;
if (response.StatusCode < 400)
{
Thread.Sleep(1000);
uow.Commit();
}
else
uow.RollBack();
}
}
}
}
Occasionally we observe that the response returns to client before calling uow.Commit() via fiddler. For example we put a break point to uow.Commit and we see the response is returned to client despite that we are on the breakpoint waiting. This is somewhat unexpected. I would think the response will strictly return after the Invoke method ends. Am I missing something?
In Owin/Katana the response body (and, of course, the headers) are sent to the client at the precise moment when a middleware calls Write on the Response object of the IOwinContext.
This means that if your next middleware is writing the response body your client will receive it before your server-side code returns from the call to await Next.Invoke().
That's how Owin is designed, and depends on the fact that the Response stream may be written just once in a single Request/Response life-cycle.
Looking at your code, I can't see any major problem in such behavior, because you are simply reading the response headers after the response is written to the stream, and thus not altering it.
If, instead, you require to alter the response written by your next middleware, or you strictly need to write the response after you execute further logic server-side, then your only option is to buffer the response body into a memory stream, and than copy it into the real response stream (as per this answer) when you are ready.
I have successfully tested this approach in a different use case (but sharing the same concept) that you may find looking at this answer: https://stackoverflow.com/a/36755639/3670737
Reference:
Changing the response object from OWIN Middleware
I have a WebAPI controller that takes an ODataOptions parameter.
I want to make sure the user can't download the whole database in one swoop.
So I validated the options object:
public IHttpActionResult Get(ODataQueryOptions<ViewModel> options)
{
var oDataValidationSettings = new ODataValidationSettings
{
MaxTop = 100
}
try
{
options.Validate(oDataValidationSettings);
}
catch (ODataException ex)
{
return BadRequest("OData query validation failed: " + ex.Message);
}
//return results
}
This works great for calls like
http://host/api/controller?$filter=...&$top=1000
This returns the expected validation error message.
But it is trivially easy to circumvent by simply making a request to:
http://host/api/controller?
No $top, no nothing. This in effect returns the whole table!
The validator is not triggered if the $top parameter is not specified at all.
I could append a .Take(100) when constructing the query from the oData options, but it seems hacky.
Is there any better way to deal with a missing $top?
You can try to use PageSize which will limit the number of entity been returned.
Refer to this example for how to use it.
https://github.com/OData/ODataSamples/tree/master/WebApi/v4/ODataPagingSample
This must be simple and already answered, but I've wasted many hours on it. I can't figure how to get an error page on mistyped address. Also I'd prefer not to redirect, but to keep the URL. I've tried many combinations of CustomErrors, HttpErrors and Application_Error, but nothing works for non-existent controller - depending on HttpErrors I always get IIS 404.0 page or just an empty 404 response. Running on IIS 7.5, MVC 3.
I don't remember where I got the solution. But here is the code to handle the error:
First, you create a ErrorController:
public class ErrorController : Controller
{
//
// GET: /Error/
public ActionResult Index()
{
return RedirectToAction("Index", "Home");
}
public ActionResult Generic()
{
Exception ex = null;
try
{
ex = (Exception)HttpContext.Application[Request.UserHostAddress.ToString()];
}
catch { }
return View();
}
public ActionResult Error404()
{
return View();
}
}
Second, open Global file and add the following code:
protected void Application_Error(object sender, EventArgs e)
{
Exception ex = Server.GetLastError();
Application[HttpContext.Current.Request.UserHostAddress.ToString()] = ex;
}
Third, change customerror in your webconfig:
<customErrors mode="Off" defaultRedirect="/Error/Generic">
<error statusCode="404" redirect="/Error/Error404"/>
</customErrors>
More: I created one more error layout. It makes things even more clear. :)
Hope this helps you.
I use the following route to ensure all requests not matching any other route fall there, then you can handle that case very easily:
// this route is intended to catch 404 Not Found errors instead of bubbling them all the way up to IIS.
routes.MapRoute(
"PageNotFound",
"{*catchall}",
new { controller = "Error", action = "NotFound" }
);
Map that last (include that statement after any other .MapRoute statements).
I have a list of addresses that i want to visit using httpWebRequest.
All i need is the statuscode returned by the server.
I have tried to foreach through them and begin a httpWebRequest on each of them, but then i only receive the callback from the last one.
It seems like only one webrequest is allowed at a time.
I'm having quite a hard time understanding how to do this without the GetResponse, which is not allowed in silverlight.
The code is running in a backgroundworker.
And i am using Mango - WP7.1
How do i solve that?
foreach (var current in Addresses)
{
var request = HttpWebRequest.Create(current);
request.BeginGetResponse(r =>
{
try
{
var response = (HttpWebResponse)request.EndGetResponse(r);
Deployment.Current.Dispatcher.BeginInvoke(() =>
{
//BOOM RECEIVED
});
}
catch (Exception)
{
Debug.WriteLine("Error in EndGetResponse");
}
}, null);
}
Thanks in advance =)
Your problem of a single response is most likely being caused by your use of anonymous methods and the the way scoping works when you put these inside loops. You are throwing away the earlier request references on each step through the loop.
See my blogpost on the topic here http://csainty.blogspot.com/2010/10/windows-phone-7asynchronous-programming.html
The simplest way to illustrate this is to rewrite your code with full methods, this forces you to consider the scope instead of just blindly referening external variables in your delegates.
foreach (var current in Addresses)
{
var request = HttpWebRequest.Create(current);
request.BeginGetResponse(EndGetResponse, new RequestState { Request = request, Address = current });
}
private void EndGetResponse(IAsyncResult result) {
try {
var state = (RequestState)result.AsyncState;
var response = (HttpWebResponse)state.Request.EndGetResponse(result);
Deployment.Current.Dispatcher.BeginInvoke(GotResponse, state.Address, response.StatusCode);
} catch (Exception) {
Debug.WriteLine("Error in EndGetResponse");
}
}
private void GotResponse(Address address, HttpStatusCode code) {
//BOOM RECEIVED
}
public class RequestState {
HttpWebRequest Request { get; set; }
Address Address { get; set; }
}
Once you solve the scoping issues you can rewrite back into anonymos methods for stylistic reasons if you like.
This will only solve your first problem of getting all the responses back however, I assume you also need to run some code when all the requests are complete to check the status of the whole batch?
That is a different problem altogether.
You can not use WaitOne() or anything like that, it will lock your thread and stop the requests from actually running at all. You will probably want to call off to another method in you BOOM code that stores away the result and checks if all the results are in yet.