I'm reading the book API Security in Action by Neil Madden. In the book, there is a section about CORS and how to attach the proper headers in Java. I am aware that there is already an AddCors and UseCors built in to ASP.NET Core, but for my edification I wanted to roll my own middleware.
However, I found that I was unable to receive any sort of OPTIONS requests, they were automatically being rejected somehow, and I was unable to respond to them manually, even when it was the first middleware in the pipeline. Since the UseCors middleware is able to intercept these pre-flight requests, I'm curious whether or not it is hooking into a deeper level of ASP.NET Core than I am able to.
TL;DR: Is ASP.NET Core (or Kestrel) performing some sort of automatic preflight request checking even when UseCors is not called?
The answer in the end is no, ASP.NET does not do anything fancy when it comes to preflight requests. I looked into the source code and the CorsMiddleware (and associated extensions) are relatively simple; most of the logic is contained within the ICorsService, and doesn't impact the middleware pipeline directly.
I'm unsure what my original issue was being caused by, but it is now resolved.
See below for the source code:
https://github.com/dotnet/aspnetcore/blob/a450cb69b5e4549f5515cdb057a68771f56cefd7/src/Middleware/CORS/src/Infrastructure/CorsMiddleware.cs
It is worth noting that if you add the CORS headers manually, you will get the following exception
System.InvalidOperationException: Endpoint ProjectName.Controllers.SomeController.Login (ProjectName) contains CORS metadata, but a middleware was not found that supports CORS.
Configure your application startup by adding app.UseCors() inside the call to Configure(..) in the application startup code. The call to app.UseCors() must appear between app.UseRouting() and app.UseEndpoints(...).
You can avoid this error by setting a flag to true in the custom CORS handler
httpContext.Items["__CorsMiddlewareWithEndpointInvoked"] = true;
However, I feel it's important to stress that this should only be done for education purposes; you should be relying on built-in CorsMiddleware and not rolling your own whenever possible (and it should hopefully always be possible).
Related
I have an xAPI content made by storyline I want for the statement to be sent to a webapp instead of the LRS.
this webapp is developped using laravel, and user should be authenticated with email and password to use it.
what I did to send the statement to this app:
1.in the webapp I created an API endpoint route that use POST method.
2.in the xAPI wrapper I changed the endpoint in the configuration to the route I made in the webapp.
const conf = {
"endpoint":"here I added my api endpoint route of the webapp",
"auth":"Basic " + toBase64(""),
}
now whith any interaction with the content where a statement should be sent the request making cors error like in the picture down, I think this is authentication error, how can I add my authentication credentials to the xAPI wrapper?
Your non-LRS LRS is probably not handling preflight requests which are necessary for CORS handling. Most common LRSs will handle those requests appropriately since they expect to be accessed from additional origins. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests
Also note that you'll likely run into issues unless you also handle state requests.
Additionally unless you are requesting the credentials from the user during runtime then hard coding the credentials into the package isn't a great idea from a security perspective.
I'm using WebApi Core 2.2. The Microsoft OData Client is adding a new parent record plus a subrecord (Deal+DealFee) from a WPF application. I'm hosting in IIS on Windows 10.
When I call container.SaveChanges(), it successfully calls the service to add the parent Deal record, but then it does a SECOND POST operation to this url (this is generated by the MS odata client lib):
POST http://localhost/mysite/odata/Deals(14)/DealFees
(note this includes the ID 14 which was just generated when adding the Deal)
This is two separate POSTs from the MS odata client lib, not a "deep insert" apparently. However, this results in a 404 (NotFound), which I can observe in Fiddler. The following urls DO work perfectly:
/odata/Deals
/odata/Deals(14)
/odata/DealFees
It seems like either the WebApi Core 2.2 service is not handling the POST to /Deals(14)/DealFees path, OR /Deals(14)/DealFees isn't a valid odata Uri? Is this kind of path generally supported in OData?
I don't know. Can anyone shed some light on what's going on?
Deep insert is not supported in WebAPI OData as of now. To me, it seems like the client is updating the resource set and the resource set for the navigation with two separate post requests and the reason you are getting a 404 is that there is no action mapped to the second request URI in the service.
The service can support this either by introducing a PostToDealFeesFromDeals controller action with default OData routing convention or use attribute routing to map the action for such requests.
If the action already exists then it might be that the first request did not finish creating the new record and the second request was fired, hence 404.
So, I am creating an application which will be using flowable.
We can say that once my application starts, it's gonna start a particular process deployed on flowable, proceed ahead accordingly.
So, in a way there will be lot of talking between flowable and other application, but for now suppose I just want to call flowable applications from POSTMAN (outside FLOWABLE).
I have used 3 modules: flowable-idm, flowable-modeler, flowable-task in my application.
Everything works fine when I am starting my deployed process from UI of flowable task, problems come when I want to start the processInstance using REST endpoint.
In flowable-task application, there is already a REST endpoint to start the process deployed: http://localhost:8080/flowable-task/app/rest/process-instances.
Now, if I call this from Swagger of flowable-task application, it works fine.
But it doesn't work when I try to call it from another application or POSTMAN for now (once POSTMAN call works, I can make the same arrangement in code), where I'm doing a basic auth and providing what's required in body.
Also, there is no error or exception displayed on console, I believe that is because of something catching that error or exception and not displaying anything.
However, to overcome the problem of starting process from POSTMAN, I can use REST endpoint http://localhost:9999/flowable-task/process-api/runtime/process-instances, but this is just a workaround, in future if I create new endpoints I would have to figure out a way to call those endpoints.
I saw this post and I guess this guy was also trying to achieve something similar but for flowable-modeler.
It's been suggested to make changes in SecurityConfiguration.java of flowable-task-conf module for my case, but I haven't done such changes before so not exactly sure where to start and how to proceed.
So, my question is how to talk to flowable-applications from outside flowable applications.
Edit:
Forum post about getting exception when imported flowable-rest module in workspace
The flowable-task UI Application is an example application that exposes non public REST API for the UI. However, the application also exposes the full REST API of Flowable.
There is also the flowable-rest application that has the Swagger doc and exposes the full REST API without a UI.
You would want to communicate with those REST endpoints.
The endpoints are under the following contexts:
process-api for the Process Engine
cmmn-api for the CMMN Engine
dmn-api for the DMN Engine
idm-api for the IDM Engine
form-api for the Form Engine
content-api for the Content Engine
For your example you would need to use POST to /process-api/runtime/process-instances for Starting a Process Instance
I'm using Glassfish 4 as a server with an AngularJS app as a client. Glassfish is exposing a REST API via JAX-RS (Jersey). I'm using Basic Authentication over an HTTPS connection. I have my own login form and am setting the Authorization header in my REST requests via JavaScript. My issue is that if I use normal web.xml based permissions (<auth-constraint> inside <security-constraint>), the responses come back with 401 with a WWW-Authenticate header (if the credentials are bad). This forces the browser to do the Basic Authentication dialog instead of my own and it appears there is no viable cross browser work around available on the browser side to stop it. So I need to somehow suppress the 401/WWW-Authenticate response.
I stopped using the web.xml based permissions, because it seems it is the Servlet level that is doing the 401 stuff. I was able to get Jersey authentication working with a filter and turning on the "RolesAllowedDynamicFeature" feature (in a matter similar to Glassfish #RolesAllowed with custom SecurityContext). That seems to work great and returns 403 for bad credentials (and thus no browser dialog). However, when I call my EJB's, they do not see the custom security context and the user I have set, so I get permission exceptions. If it matters: the EJB's are in a jar, the Jersey stuff is in a war, and both of them and bundled together in an ear. From what I can gather the only way to have the EJB's properly process credentials is to use the web.xml stuff.
I seemed to have painted myself into a corner and do not see how to make this work. Perhaps I can back out and return to using web.xml based permissions and somehow filter the servlet responses to not return 401/WWW-Authenticate? If so I could not find out how to do that. Or is there some way I can set EJB's security context? Or something else entirely? I wouldn't think using AngularJS with GlassFish and a REST API and Basic Authentication would be very unique, how does anyone do this?
Since posting this question I have found info on implementing a Servlet filter and using that to try to change the 401 response to a different status code. However, the filter never gains control if you have <auth-constraint> in your web.xml and the request is not authorized, so that did not help me. I still could not prevent the 401 responses.
But now I think I finally found the answer. I removed the <auth-constraint> tag from web.xml. I changed the Servlet filter to now extract the AUTHENTICATION_HEADER on its own and decode it (via javax.xml.bind.DatatypeConverter). Next I call HttpServletRequest.login (on the request object) with the decoded username and password. I catch the ServletException if the username/password combination is bad and use HttpServletResponse.sendError to send SC_FORBIDDEN. If I have a good login I call doFilter to continue on with processing of the request, and call HttpServletRequest.logout when it returns.
If I do this in combination with RolesAllowedDynamicFeature and annotations on the Jersey routines everything seems to work including calls to EJB's with their own security annotations.
Side note: before settling on HttpServletRequest.login I had tried to use HttpServletRequest.authenticate followed by checking the returned boolean, but when you gain control in that case the response has already been committed to be 401 and you cannot change it. I even tried passing a HttpServletResponseWrapper to authenticate to stop the commit from happening, but authenticate seems to get the response object through some other means, it seems to ignore the one you pass it (I even tried passed null and it didn't even notice).
How can I change ASP.NET Web API to never return a text/html 404 response? I'd rather it send back XML/JSON with an ExceptionMessage or Message. It doesn't make sense to return HTML from an API, IMO.
Just to clarify, this is for cases when the URL truly is invalid.
Another problem is that I am hosting MVC and Web API in the same project, so I need to respond differently. I am guessing it will depend on whether the URL starts with "api".
You do not get those HTML data if you simply call
throw new HttpResponseException(HttpStatusCode.NotFound);
somewhere in your ApiController's methods.
You get this page only when routing mechanism can't fit your request to any of your ApiController's methods. So the HTML message is attached on the application level not in ApiControllers. Here is very good example how you can handle errors in your ASP.NET application Custom error pages on ASP>NET MVC3.
I would even go further and check if the request comes to WebAPI (not to MVC), and if so redirect to IHttpActionResult in ErrorsContoller.
How to prepare IHttpActionResult for response you can read here Action Results in Web API 2
Have you tried using an Exception Filter? This may allow you to capture exceptions and then set the response type "applications/json", message, etc.