How to prevent HTTP and allow HTTPS? - java

How to check the URL is http or https through programmatically using HttpServlet. If the Url is http send message as Warning otherwise message as Allow.
How to prevent HTTP Url and allow HTTPS through programmatically.

You can detect HTTPS inside a servlet via servletRequest.isSecure().
To force use of HTTPS, just configure secure Urls in your web.xml. The when users go to HTTP they will be redirected to HTTPS.

Related

AADSTS500112: The reply address 'http://testurl' does not match the reply address 'https://testurl' when requesting Authorization code

i'm trying to integrate java application with azure ad .
i have registered an app in azure and added redirect url's , after successful login , it was redirected to my java application where i am fetching authorization code using msal library.
Getting the below exception
com.microsoft.aad.msal4j.MsalServiceException: AADSTS500112: The reply address
'http://testUrl' does not match the reply address 'https://testUrl
the only difference i see in the above url's is http and https, even though i mentioned https in both redirect url in the app registrations as well as redirect_uri in the microsoft login url.
btw, it was working with my local environment, not working when i hosted it on the server .
We had the same issue after it was deployed in production environment. The reason the https became http is since I was in a load-balanced environment, the outside URL differed from the inside URL (The load balancers off-loaded the SSL processing). When the http request from azure reached our web filter, the httpRequest.getRequestURL().toString() get the http instead of https. What we did is, ask devops team to add a header in httprequest with the original url sent to load balancer, and in our code, we extract the http header instead of the http request itself.
Specifically, change
String currentUri = httpRequest.getRequestURL().toString();
to
String currentUri = httpRequest.req.getHeader(HEADER_PROXY_URL);
The HEADER_PROXY_URL is the header name that devops inject the original url.
According to my research, the redirect URL for web apps and services must begin with the scheme https. If you want to use the scheme http, you just can use http:\\localhost. For more details, please refer to https://learn.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison#restrictions-on-redirect-urls

My Application is not responding to the request given by front end and throwing a CORS exception

I have created a web service using dropwizard.
Through this, I am able to create resources, wherein I have created an entity for indexing the document, search request, getting doc by id.
By hitting the API in postman I get the desired result.
For developing the web application I built the front end using ember.js.
But when I send a request to my application I am getting CORS policy exception.
When I am sending request through postman to http://localhost:9090 (9090 is the port number of my ApplicationConnector) then it is responding to the request.
Now when I send request from origin http://localhost:4200 (4200is the default port number for ember.js) to http://localhost:9090 it is giving error :
Access to XMLHttpRequest at http://localhost:9090/{indexName}/{id} >from origin http://localhost:4200 has been blocked by CORS policy: Response to preflight request doesn't pass access control check:
No 'Access->Control-Allow-Origin' header is present on the requested resource.
So can someone please explain how to resolve this issue and if there is any other way apart from enabling CORS in Dropwizard ?
You need to enable CORS in Dropwizard or serve both the frontend and the API from the same host (hostname and port). Otherwise it's forbidden by CORS security feature, which is enabled by default in all major browsers. Postman does not care about CORS.

Check the XForwardedProto in Spring Framework

I have followed the techinical guidance in the below link. But I am not able to get a clear idea how i can configure that in my spring rest framework.
Offloading https to load balancers with Spring Security
My requirement is before the actual request comes to my rest api, it's hitting the Amazon elb. Elb is converting https to http. But I need to check the original request is HTTPS and it's properly converted to HTTP using the ELB.
I have gone through the SecureChannelProcessor and InsecureChannelProcessor.
I am expecting my request should be HTTPS before hitting the ELB and after the ELB it should be HTTP. That validation check should be handled in my REST API Code. END USER REQ ---(https)----> ELB -------(http)--> REST API in my rest api, I should be able able to check the X-Forwarded-Proto (Or request type) should be https and it's been converted as http in my ELB.
But Not getting a clear idea. Any help will be appreciated.

Is it possible to add headers for CORS at the calling side server?

I have a GWT appilcation in which the client makes a request to another domain.
I wrote the request using RequestBuilder in GWT.
On executing the code, I get an error in my browser :
No 'Access-Control-Allow-Origin' header is present on the requested resource.
So I google and I found that the domain to which I am making the request should add this header in the response that it sends. Now I dont't have control over the other domain's server, so I can't do any modification there.
My question is, can I intercept the response and the Access-Control-Allow-Origin header to the response that is being sent by the other domain's server at my server, before I send it to my client?
I tried using Filters but the Filter doesn't get called for responses coming from another domain.
Is this possible to do, am I missing something or is it just not possible?
Vivek's answer that cross domain requests aren't allowed by the browser is true, except for the CORS mechanism, whereby newer browsers that support it can try in a cross origin way to servers that also support it.
However, unless that remote server support it itself, there is nothing you can do. If I server my app from A, and want to connect to B, only B can authorize that. If A were allowed to permit my app to connect to B via some filter or servlet, then I could write an app that makes calls to gmail or facebook or twitter and read/write your settings and personal data at those other urls.
So instead, it is the cross origin server that you are contacting that must approve the connection with the header you mentioned. In lieu of that, you can still use your own server as a proxy for the cross origin server.
Cross-domain requests are forbidden by web browsers as per the same origin security policy. These restrictions are limited to browser based applications and hence you can definitely use your own server application as a filter between the GWT based client side application and the external server.

Send http headers from servlet to app in another environment

I need to send a request from a servlet to an application running in other environment (IIS) with certain information in custom headers.
I know redirecting doesn't send the headers and getServletContext().getRequestDispatcher(url) is to be used in the servlet's context only. Has anybody made this work in some other way? I was thinking in using HttpURLConnection, but would it finally redirect the browser to the targeted app ?
Thanks in advance
You can't redirect from your servlet to the external server and keep the headers, and you can't forward the incoming request to other context.
What you could do, is to use the HttpURLConnection (or other http client library such as HTTPClient) to make the request (with the custom headers you need) to the remote server and, once the operation is complete, redirect the user to the external site (customm headers are not set in this redirection).
This is a little tricky, if you elaborate your question (what do you really need to do) we can probably think about other alternatives.
AJAX? You can send some JavaScript code to the browser which sends a request to the ISS and handle (shows) its answer. It's possible to set http headers with XMLHttpRequest but it needs client side JavaScript coding and you have to find a way to send cross domain requests.

Categories