I am using GWT. Currently using gwt-rpc to for login authentication. For only login purpose i want to use ssl(https) and so instead of using gwt-rpc i am trying Request Builder and calling a servlet with https.
When in Servlet URL i use protocol as http the request builder works perfectly and response returns to client side(onResponseReceived ). but when i use https in the servlet url then the servlet is gettting called but the response is not returning to the onResponseReceived method of request builder.
my url with http looks like : http://localhost:8888/myproject/myservlet
and with https it looks like :https://localhost/myproject/myservlet
Please give any suggestion or is there any other way to do it.and also is it possible to use ssl over gwt-rpc.
Browser Same origin policy is blocking your requests.
Your page was requested over http, but you are now making an ajax call over https. This is a violation of same origin policy.
To get around, you should serve your original html/servlet over https. This does have a performance cost, but it is the only way to build a secure website.
I'm not familliar with GWT and Request Builder, but whenever I have had problems with HTTPS connections from my code it has come down to certificates and having the right certificate installed in the client or telling the client code where to find the certificate in order to encode the call.
That would be the first avenue I would want to explore in your situation.
Related
I am fetching a GET API using the fetch command in react. When I run the production build, I can see the x-api-key in request header when I inspect in either Google/Firefox (network). This is the API key that my web app uses to make the request and I don't want it to get exposed in the browser's devtools. Any ideas on how to achieve this?
Fundamentally, you rewrite some stuff and proxy the request server side.
There is no way to hide the x-api-key header if you are directly making the request from the client. The only way is to make it from the server, then provide the results to the client.
I have an api gateway installed that I'm trying to program against. Requests work when using apps like Postman but when I try to connect through code in the form of XMLHTTPRequests I get 401... No 'Access-Control-Allow-Origin' header is present on the requested resource. saying that the server doesn't allow cross site calls.
Maybe I'm not fully understanding how this works but it seems that apps like Postman circumvent this somehow. Whereas when I'm trying to access the api from a local file in my browser I bump into this problem.
Do I need to host the webpage I'm calling from to get this to work? Or am I missing something else here?
When the browser issues a XMLHTTPRequest, it checks if the origin (i.e. the domain) of that request is allowed by the endpoint to send requests. The check is done by a preflight request, i.e. a HTTP OPTIONS request which should provide a response containing a Access-Control-Allow-Origin header with the domain originating the request (or * to allow all domains).
Since this is a security measure of the browser, mainly based on the fact that browsing web pages the user may not know which requests are sent to which endpoints, Postman simply does not need to apply it because its requests are explicitly sent by the user himself.
https://developer.mozilla.org/en-US/docs/Glossary/CORS
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
My application is running under HTTPS with a valid certificate from one of the known authorities. Unfortunately I am using a third party API which doesn't support HTTPS.
The result is the known message Mixed content: mydomain.com requested an
insecure XMLHttpRequest endpoint.
Is it possible to add an exception to the web server to allow calling this API insecurely!! I am using Nginx BTW.
If not what what can be other possibilities to solve this problem.
I have a solution but I don't like it because it will be a performance drawback:
Implement an API which acts as proxy, receive the requests from the application through HTTPS and make the requests to the third party API throw HTTP.
I too had this issue. Everything on a page should come and request https if you are using https and don't want warning/errors. You don't need to implement an api to proxy if you are using nginx. Whatever you implement will be performance hit as you correctly surmise. Just use proxy pass in nginx.
In our configuration, we have :
location /thirdparty/ {
proxy pass http://thirdpartyserver/;
}
Notice the trailing slash in proxy pass, I keep all third party api which are http in https://myserver/thirdparty/requesturl. Trailing slash removes thirdparty while making request. So it becomes, http://thirdpartyserver/request
Official reference: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
In order to allow mixed content, the individual users must allow it in their browsers. Allowing HTTP content from one source is enough to compromise the security of HTTPS, so browsers forbid mixed content by default. The solutions I see are:
Getting rid of HTTPS (which I would NOT recommend)
Doing what you suggested and proxying requests through (this still isn't great security-wise)
Get rid of the HTTP content
Google has some recommendations for developers under step 1 (but they are basically echoed above): https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content#step-1
I am trying to use Dropwizard as a full web server, combining serving public pages, protected pages and data through REST API. So, I am validating the ability to protect some routes by applying a custom authorization scheme based on a computed token and a realm to manage different security areas.
I have difficulties to understand how to achieve the purpose. The sequence I was expecting is the following :
display an HTML login page with a user form
user enters its credentials
call an authenticate route to validate credentials and create a token for the user. Send back a welcome page with an Authorization header like : MyScheme token="TYGDF655HD88D098D0970CUCHD987D897", realm="SUPER SECRET STUFF"
user click a link to list its invoice : /html/invoices
this route is protected by DropWizard #Auth annotation
no header is sent by the browser so the server answer with a 401 response with a header : WWW-Authenticate MyScheme realm="SUPER SECRET STUFF", challenging the browser to give it an authorization header matching the challenge
Unfortunatly, the browser didn't send it this header. According to many articles, I thought browser managed authorization cache for all received credentials, their scheme and parameters (such as realm).
It seems browser have this behavior for well known schemes such as Basic authentication, but not for custom scheme (by the way, it's usually an issue for basic auth since browser can't "logout" a user since he does not erase the web history or close the browser).
How do you think it's possible to tell a browser to cache authorization credentials and to add them each time a server request is challenging it with the right scheme / realm ?
I could display here all the example codes I use to make this example run.
A reference (good to read) : RFC1945 at https://www.rfc-editor.org/rfc/rfc1945#section-11
Thank you for your help.
Running dropWizard 0.9.2 on Jdk Oracle 1.8 / Debian 8.
Browser doesn't manage authorization. It never does, or at least never should.
Server should always keep its cache, and verify input from the browser.
At a basic level, all of the fields you need, are part of the HTTP Header. If you inject the request, you'll have access to them.
If dropwizard doesn't have things you need, you can always ignore everything, and simply read the request headers and do the custom processing you need.
For instance, add a Filter which sets the realm, something like WWW-Authenticate: Basic realm="myrealm:"
Authorization: MyScheme Ceasar-cipher-password. You'll need to parse it and process it yourself, perhaps set up an incoming Filter on all requests, or selective requests.
Is it a good idea, I'll let you be the judge. Perhaps, in your use case it makes sense.
If you have a look at the source code and how the BasicCredentials are used, perhaps, it can provide insight in a potential solution you may adapt yourself.
Hope it helps.
I have a question regarding the Tuleap REST API when used with CORS.
Basically, I'm trying to make a REST call to see the backlog of my project.
Referring to the API Explorer, to do so I need to do a GET call like this: /api/projects/{id}/backlog I also need to add the custom headers X-Auth-Token and X-Auth-UserId to ensure the authentication.
When I do this request with a HTTP Request tool (Poster for Firefox) everything works fine and I get status 200.
The problem now is that I'm trying to develop an application (in angularJS) that would do the same request.
I noticed that when the page is doing the request, it starts by doing a preflight OPTIONS request which is due to the Cross-Origin-Ressource-Sharing.
It seems like the X-Auth-Token and X-Auth-UserId header are being put in the Access-Control-Request-Headers. Because of that I get an unauthorized 401 response code from the server and I can't complete the request.
I've been looking online and couldn't find my answer as how to make this call work.
There was a recent contribution that should remove the need for authentication on all OPTIONS routes in order to enable the preflight: http://gerrit.tuleap.net/#/c/2642/ It was
Integrated in Tuleap 7.2.99.36
Either your version of Tuleap is too old or there is a bug.
Note all calls still require some headers such as "Content-Type: application/json"; the integration tests should provide good examples of how to make calls:
https://tuleap.net/plugins/git/tuleap/tuleap/stable?p=tuleap%2Fstable.git&a=tree&h=9a513f2b7e765f7b9a4f7f72e9d43f40f623fec5&hb=293d47e4006531d3c0d04edfc6e7058e53c7c9c8&f=tests/rest
and
https://tuleap.net/plugins/git/tuleap/tuleap/stable?p=tuleap%2Fstable.git&a=tree&h=4d9071865a42cbd0d40f5f933b4b0b1047c54a8c&hb=293d47e4006531d3c0d04edfc6e7058e53c7c9c8&f=tests/lib/rest