I've been using restlet camel component to communicate with endpoints fine for a couple of weeks now, but after I had the need to add an Authorization header to my requests, that's when I kept getting this warning:
WARNING: Addition of the standard header "Authorization" is not allowed. Please use the equivalent property in the Restlet API.
Which blocks the header from being added to the outgoing message.
I've seen solutions for this for using restlet, but I don't have the luxury when using it as a camel component.
I've tried using the org.restlet.http.headers attribute but still get the same message.
Any ideas how to make it send out my authorization header?
(I would rather not use the http component)
Note: I'm using Camel 2.19.2, same version for restlet
There is a ticket at Restlet to support this, however they have not implemented this: https://github.com/restlet/restlet-framework-java/issues/1198
There is also a Camel ticket: https://issues.apache.org/jira/browse/CAMEL-10665
As it seems Restlet takes forever to fix this on their side, we may have to bit the bullet and make a special fix in the camel-restlet component
Related
Im am trying to call a rest post service from my Camel route.
The rest service is deployed at https://csp-verteileauftrag-camunda-v1-csp-ims-dev-az.apcn.osp4-preprod.hel.kko.ch/api/v1/verteileauftrag/.
Calling the Service from a Rest Client like VS Code works if there is a trailing slash (after verteileauftrag).
In my camel route I have configured the following:
restConfiguration().host("https://csp-verteileauftrag-camunda-v1-csp-ims-dev-az.apcn.osp4-preprod.hel.kko.ch/api/v1").component("http").bindingMode(RestBindingMode.json);
and in then later using the config:
.to("rest:post:verteileauftrag?outType=ch.helsana.csp.verteileauftrag.rest.model.apiadapter.ResponseType")
If I execute the code, I get a 404 HTTP Error from the Backend as the URL used is
https://csp-verteileauftrag-camunda-v1-csp-ims-dev-az.apcn.osp4-preprod.hel.kko.ch/api/v1/verteileauftrag. So without a trailing slash.
I have tried to add it like .to("rest:post:verteileauftrag/?outType=ch.helsana.csp.verteileauftrag.rest.model.apiadapter.ResponseType")
but no success.
Do you have any idea how to tell the http component in the rest configuration how to add the trailing slash?
Thank you very much.
Using redhat fuse 7_10_2.
Regards Michel
Based on a collegues example I reimplemented the Rest Service call with a normal .to("URL") configuration in the routebuilder with setting the appropriate Headers for HTTP Post and content type json. Would still be interessted in any answer, but not waiting on one.
I'm trying to run a simple test with Apache Camel:
from("http://localhost:61554/api/v1/MyController/my-endpoint")
.to("direct:a")
.log("$({body}");
I'm getting the following error: "No endpoint could be found for: http://localhost:61554/api/v1/MyController/my-endpoint, please check your classpath contains the needed Camel component jar"
I'm very new to Camel and Java. Can someone please tell me why this error is coming up? Should I be using from("direct:x")... ? If, so where do I map my "direct" endpoints to concrete ones?
Thanks
You cannot use the http component as consumer (eg in from) - its a http client for calling HTTP servers (so its a producer, eg to).
Instead to have HTTP as consumer you can use camel-servlet, camel-jetty, camel-undertow, etc.
I am having frontend in React and backend in Spring boot. I am having GET/PUT/POST/DELETE HttpMethods in Rest API, but for every request from the client OPTIONS call is sent by the client(browser). Due to security reasons, I need to restrict these OPTIONS method call from the client. At this moment of time changing on API level is not feasible Is there any configuration kind of thing to prevent this.
React application is deployed on IIS and Spring boot application on Tomcat.
React application using Axios as HTTP Client.
Note: I know the preflight request is sent by browser and for this OPTIONS are getting invoked, I don't want to go in that direction.
These OPTIONS requests are part of the CORS specification which states that every PUT or POSTs with content type application/json must be preflighted with OPTIONS to check Access-Control-Allow-Origin header without causing any side effects.
I can't see any security issues with allowing OPTIONS, but in fact this is a security feature enforced by your browser.
To stop this behavior you should use same origin requests. Other possibilities which I won't recommend would be to just use GETs for your post requests or POST with content type other that application/json. And of course, you can write your own browser or connect from a native environment (as HttpClient on a desktop or mobile app).
I originally wrote an REST API to work with a previously written mobile app. The mobile programmer requested from me to generate an auth_token on login that he will pass as a header on each request that needed authentication. This API runs at api.example.com.
Later on, I was commissioned to write an AngularJS app that communicates with this API, so I had to use Access-Control-Allow headers on the backend for OPTIONS requests to be CORS compatible CORS so my browser allows the connection (looks like iOS does not look for this headers). This app runs at one.example.com.
Now, I have to write a second AngularJS app that will run at two.example.com and there's a third being planned for the near future at three.example.com.
My problem is that my Access-Control-Allow-Origin header looks like this:
Access-Control-Allow-Origin: http://one.example.com:80
* is not allowed, nor I'm able to set this header to more than one origin. So as far as I can see I have two solutions:
Implement token-based authentication in parallel to the current cookie-based one. I'm thinking on this. This will of course take some time I'm willing to save.
Send the requester a header or param to the API endpoint identifying the app on the OPTIONS request and server-side, produce the CORS headers accordingly. I don't even know if it's possible and this looks nasty for even thinking it.
Any better ideas?
If they have the same origin, example the same domain (example.com) or the same subdomain (1.ex.example.com and 2.ex.example.com) they can share the same cookie. Because cookie is based on the domain itself.
I'm building a RESTful API with the Restlet framework and need it to work with cross domain calls (CORS) as well as basic authentication.
At the moment I'm using the CorsFilter which does the job of making my webservice support CORS requests. But, when I try to use this with a simple ChallengeAuthenticator with HTTP Basic Authentication it won't work as I want it to (from a web site).
When I access the webservice directly via Chrome it works as intended, but when I try it in a small web application written in angularjs (jquery/javascript) and try to access the webservice it does not.
Basically what happens is that when a OPTIONS request is sent to my webservice it will not respond with the headers: 'Access-Control-Allow-Origin', 'Access-Control-Allow-Credentials', etc. as it should. Instead it is sending a respond with HTTP status code 401 saying that the authentication failed.. Is this because the authenticator is overriding the CorsFilter somehow?
My createInboundRoot method can be seen below.
#Override
public Restlet createInboundRoot() {
ChallengeAuthenticator authenticator = createAuthenticator();
RoleAuthorizer authorizer = createRoleAuthorizer();
Router router = new Router(getContext());
router.attach("/items", ItemsServerResource.class);
router.attach("/items/", ItemsServerResource.class);
Router baseRouter = new Router(getContext());
authorizer.setNext(ItemServerResource.class);
authenticator.setNext(baseRouter);
baseRouter.attach("/items/{itemID}", authorizer);
baseRouter.attach("", router);
// router.attach("/items/{itemID}", ItemServerResource.class);
CorsFilter corsFilter = new CorsFilter(getContext());
corsFilter.setNext(authenticator);
corsFilter.setAllowedOrigins(new HashSet(Arrays.asList("*")));
corsFilter.setAllowedCredentials(true);
return corsFilter;
}
(The authorizer and authenticator code is taken from the "official" restlet guide for authorization and authentication)
I've tried alot of changes to my code but none which given me any luck. But I noticed that when setting the argument "optional" in ChallengeAuthenticator to true (which "Indicates if the authentication success is optional") the CorsFilter does its job, but obviously the ChallengeAuthenticator does not care about authenticating the client and lets anything use the protected resources..
Has anyone had a similar problem? Or have you solved this (CORS + Authentication in Restlet) in any other way?
Thanks in advance!
I think that it's a bug of the Restlet CORS filter. As a matter of fact, the filter uses the method afterHandle to set the CORS headers. See the source code: https://github.com/restlet/restlet-framework-java/blob/4e8f0414b4f5ea733fcc30dd19944fd1e104bf74/modules/org.restlet/src/org/restlet/engine/application/CorsFilter.java#L119.
This means that the CORS processing is done after executing the whole processing chain (authentication, ...). So if your authentication failed, you will have a status code 401. It's actually the case since CORS preflighted requests don't send authentication hints.
For more details about using CORS with Restlet, you could have a look at this link: https://templth.wordpress.com/2014/11/12/understanding-and-using-cors/. This can provide you a workaround until this bug was fixed in Restlet itself.
I opened an issue in Github for your problem: https://github.com/restlet/restlet-framework-java/issues/1019.
Hope it helps,
Thierry
The CorsService (in 2.3.1 coming tomorrow) contains also a skippingResourceForCorsOptions property, that answers directly the Options request without transmitting the request to the underlying filters and server resources.