how it's going?
I have a RestApi built in Spring. There are some functional endpoints using GET and POST Methods. I tried add a https configuration as below:
#Configuration
public class ServerConfig {
#Bean
public ServletWebServerFactory servletContainer() {
TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory() {
#Override
protected void postProcessContext(Context context) {
SecurityConstraint securityConstraint = new SecurityConstraint();
securityConstraint.setUserConstraint("CONFIDENTIAL");
SecurityCollection collection = new SecurityCollection();
collection.addPattern("/*");
securityConstraint.addCollection(collection);
context.addConstraint(securityConstraint);
}
};
tomcat.addAdditionalTomcatConnectors(getHttpConnector());
return tomcat;
}
private Connector getHttpConnector() {
Connector connector = new Connector(TomcatServletWebServerFactory.DEFAULT_PROTOCOL);
connector.setScheme("http");
connector.setPort(8080);
connector.setSecure(false);
connector.setRedirectPort(8081);
return connector;
}
}
Before I had like http://localhost:8080/api/candidates [GET] and after added this class, the url was redirecting to https, what is normal, so now I am redirecting to https://localhost:8081/api/candidates.
After that I have done this, when I try access the endpoint without HTTPS http://localhost:8080/api/candidates using GET I can retrieve all information, but when I try using POST to send some data I receive
Method not allowed but GET is working yet. Does anyone knows why?
I found this post, and it was exaclty what I was looking for. If you want see please check Spring Boot: redirect from HTTP to HTTPS results in 405 error for PUT method
A redirect is specifically to inform the client (e.g. web browser) to
do a GET request using a given URL, so the result of a redirect cannot
be a PUT, POST, DELETE, or any other HTTP method.
In this context, the main purpose of redirecting to HTTPS is to secure
the connection from snooping, i.e. ensure that no one can see
confidential information. This works well for a GET, since you haven't
sent confidential information yet1, assuming it is the response that
contains confidential information.
Redirecting a PUT or a POST to HTTPS is meaningless, since you already
sent the payload (the confidential data) over an unsecure connection.
Your client needs to be told to use HTTPS before it sends the data,
i.e. when it builds the PUT / POST request, it needs to be given an
HTTPS URL.
Fix the client code, e.g. the JavaScript code that generates the HTTP
PUT, so it uses HTTPS. Redirecting is too late, and entirely wrong.
It is actually a good thing that redirect of PUT failed, because it
forces you to correctly secure your web application. If it hadn't
failed, you'd mistakenly have thought that you web application was
secured by the redirect, when in fact it wasn't.
Redirecting GET requests is not the same as redirecting POST requests. Please read this. They state following:
Redirecting GET requests, which contain no data other then a query string, is a simple process. However, POST requests are more difficult to redirect because a browser responding to a 302 or 301 redirection converts an initial POST request to a GET request—a process that loses the original POST request data.
Related
I am trying to implement Keycloak as an IAM, the Problem that I have is, that I need to authenticate the user (already working) but also authorize him. The authorization should be accomplished through keycloak directly, but the security information (like roles, etc.) is available over an REST interface externally.
The way it is working now goes as followed:
authentication request (default)
"authorization" request → keycloak server (with extra form param)
keycloak server → CustomProtocolMapper (calls external REST interface and adds claims to Token)
Token → frontend client
This worked until I used a refresh token to refresh the ID Token. The Cookie that is used to authenticate the user is not sent to the keycloak server, because of security reasons (Cookie labeled as "Secure" but connection over HTTP). To fix this I upgrade my keycloak server to use HTTPS/TLS and now i am getting errors because the "HttpRequest" is no longer available. Any ideas on how to get the Request Body of an HTTPS Request inside a CustomProtocolMapper? I know that the Authenticator Providers has access to it, but i dont know/ didnt find anyway to add claims to the Token inside it.
#Override
protected void setClaim(IDToken token, ProtocolMapperModel mappingModel, UserSessionModel userSession, KeycloakSession keycloakSession,
ClientSessionContext clientContext) {
String contextParamName = mappingModel.getConfig().get(CONTEXT_PARAMETER);
// worked with http
HttpRequest request = keycloakSession.getContext().getContextObject(HttpRequest.class);
String contextId = request.getFormParameters().getFirst("activeContext");
LOGGER.warn("activeContext: " + contextId);
}
Thanks in advance,
best regards
I have the following code running as part of a custom filter:
Cookie cookie = new Cookie("NAME", "VALUE");
cookie.setMaxAge(Integer.MAX_VALUE);
response.addCookie(cookie);
When running UT using Jetty server I receive the cookie successfully from the servlet.
Nevertheless, when I'm running a local Tomcat server (using IntelliJ), the cookie is not even set on the server side (i.e. not a client issue). The only cookie I can see is the jsessionid cookie.
I tried the following with no luck:
setDomain("")
setPath("/")
response.flushBuffer() after adding the cookie.
I'm printing all the response cookies right after I added the new cookie, but my cookie is not listed.
Collection<String> headers = ((HttpServletResponse) res).getHeaders("Set-Cookie");
for (String header : headers) {
System.out.println("Session Cookie:" + header);
}
I'm pretty new to web application and Java in general, so it is also possible that I missed something very basic.
Will appreciate any help here.
I found the answer here: http://www.coderanch.com/t/577383/jforum/response-addCookie-work-filter.
In short: "Adding a cookie requires modifying the HTTP headers of the response. Once the response has been "committed", e.g. anything written to the output stream, you can not modify the HTTP headers. The response has been committed by the time you try to add your cookie...Most JSP implimentations and some servlets will actually generate the response in a buffer. This means the response isn't committed the output is closed or manually flushed. So, this would work in some applications and not in others".
Bottom line, I needed to update the response before the chain.doFilter(req, res) has been called.
I have some servlets running in Jetty, deployed on Heroku, handling POST requests.
Some, but not all, POST requests MUST come over https. Whether or not a request should be forced to be on https depends on the http body of the POST request.
I need to figure out, from inside the servlet, whether the incoming request used https (SSL) or not, so that I can send the appropriate response. However, nothing I have tried seems to work.
I tried the obvious HttpServletRequest.getProtocol() but that apparently returns the same constant whether the protocol was http or https.
I tried HttpServletRequest.isSecure() however that is returning false even though my test request was sent to a url starting with https://
When I call HttpUtils.getRequestURL( HttpServletRequest ).toString(); I get an apparrently reconstructed url that starts with "http://" even though my test request was sent to a url starting with "https://"
According to the post "Enforce HTTPS with Embedded Jetty on Heroku" heroku has some load balancers, and I should get the value of the "x-forwarded-proto" header. That header is blank.
FYI I am using the default SSL endpoint provided by the heroku api -- I am not using their SSL Endpoint extension, because this url is not being loaded in a browser (so I don't need a custom domain in the url).
Can anyone tell me how to tell if HTTPS was used in the incoming request?
I know nothing about Heroku, but if you're programmatically configuring Jetty (as opposed to using the XML configuration), you likely need to add the SecureRequestCustomizer to your HttpConfiguration. It sets the secure flag on the requests, as well as setting the scheme to HTTPS. You can find examples here, but briefly:
final HttpConfiguration httpConfig = new HttpConfiguration();
httpConfig.setSecurePort(httpsPort);
final ServerConnector httpConnector = new ServerConnector(server,
new HttpConnectionFactory(httpConfig));
httpConnector.setPort(httpPort);
server.addConnector(httpConnector);
final HttpConfiguration httpsConfig = new HttpConfiguration(httpConfig);
httpsConfig.addCustomizer(new SecureRequestCustomizer()); // !!!
final HttpConnectionFactory httpsFactory = new HttpConnectionFactory(httpsConfig);
final SslConnectionFactory sslFactory = new SslConnectionFactory(sslCtx,
httpsFactory.getProtocol());
final ServerConnector httpsConnector = new ServerConnector(server,
sslFactory, httpsFactory);
httpsConnector.setPort(httpsPort);
server.addConnector(httpsConnector);
I too found it rather surprising that this poorly documented step was necessary.
I have a legacy Java webapp that does MANY redirects and forwards. I'm trying to find a way in a ServletFilter to differentiate GET requests from those server side redirects and GET requests that come from the client side.
I was hoping to do that by adding an attribute as a flag, to the header before the redirect/forward is sent and then read it in the ServletFilter to route it accordingly.
I tried request.setAttribute("myflag", "yes") before the redirect and request.getAttribute("myflag") in the ServletFilter. All I got were null values.
Can I modify headers server side and read those modifications server side?
Thanks in advance for any tips.
You can use a HttpServletRequestWrapper, there is a comprehensive tutorial on how to do that here:
http://vangjee.wordpress.com/2009/02/25/how-to-modify-request-headers-in-a-j2ee-web-application/
don't use request.setAttribute()/request.getAttribute() , it's scopes on forwards.
you can use Cookies.
If your application sets a request attribute and then forwards the request, the filter (if executed) on the forwarded URI will see the request attribute values.
In contrast, if the application sets a request attribute and then issues a redirect on the response, the browser issues a new HTTP request to the next URI - so previous request object attributes are not persisted and you'll get null values.
You could use this technique to determine which requests were redirects vs forwards.
For example:
Servlet A executed at URI /webapp/a calls request.setAttribute("forward", Boolean.TRUE) and then response.sendRedirect("/webapp/b")
If you have a servlet filter mapped to /webapp/b, in the scenario above, request.getAttribute("forward") will be null.
If, however, /webapp/a asks RequestDispatcher to forward to /webapp/b, then the call to request.getAttribute("forward") within the servlet filter's doFilter() will yield Boolean.TRUE because the request object is the same. It can then deduce that the request was forwarded (or included) and not a redirect OR a direct GET request to /webapp/b.
We have a JSF web application that uses Acegi security. We also have a standalone Java Swing application. One function of the Swing app is to load the user's home page in a browser window.
To do this we're currently using Commons HttpClient to authenticate the user with the web app:
String url = "http://someUrl/j_acegi_security_check";
HttpClient client = new HttpClient();
System.setProperty(trustStoreType, "Windows-ROOT");
PostMethod method = new PostMethod(url);
method.addParameter("j_username", "USERNAME");
method.addParameter("j_password", "PASSWORD");
int statusCode = client.executeMethod(method);
if (statusCode == HttpStatus.SC_MOVED_TEMPORARILY ) {
Header locationHeader= method.getResponseHeader("Location");
String redirectUrl = locationHeader.getValue();
BrowserLauncher launcher = new BrowserLauncher();
launcher.openURLinBrowser(redirectUrl);
}
This returns a HTTP 302 redirect response, from which we take the redirect url and open it using BrowserLauncher 2. The url contains the new session ID, something like:
http://someUrl/HomePage.jsf;jsessionid=C4FB2F643CE48AC2DE4A8A4C354033D4
The problem we're seeing is that Acegi processes the redirect but throws an AuthenticationCredentialsNotFoundException. It seems that for some reason the authenticated credentials cannot be found in the security context.
Does anyone have an idea as to why this is happening? If anyone needs more info then I'll be happy to oblige.
Many thanks,
Richard
I have never done Acegi/SpringSecurity, but the symptoms are clear enough: some important information is missing in the request. You at least need to investigate all the response headers if there isn't something new which needs to be passed back in the header of the subsequent request. Maybe another cookie entry which represents the Acegi credentials.
But another caveat is that you in fact cannot open just the URL in a local browser instance, because there's no way to pass the necessary request headers along it. You'll need to have your Swing application act as a builtin webbrowser. E.g. get HTML response in an InputStream and render/display it somehow in a Swing frame. I would check if there isn't already an existing API for that, because it would involve much more work than you'd initially think .. (understatement).
In this case you can do Basic Authentication and set this header in every request instead of sending the jsessionid:
AUTHORIZATION:Basic VVNFUk5BTUU6UEFTU1dPUkQ=
The token VVNFUk5BTUU6UEFTU1dPUkQ= is the username and the password encoded base64.
Example:
scott:tiger
is:
c2NvdHQ6dGlnZXI=
One more thing: use SSL.