I'm currently creating an application, in which I use code like this:
session.user = user.username
Hence I get JSESSIONID cookie created. But I want my client side program to read this cookie; But since its been set HttpOnly to true I can't get value from client side.
How one should change the cookie Httponly to set false in grails? So that client side code can read them?
Thanks.
The httpOnly setting isn't a Grails option but rather an option of the container running your application (Tomcat in your example). Thus these changes are going to be related to Tomcat more than Grails.
Normally Grails creates the web.xml for Tomcat at compile/runtime and while you could use the eventConfigureTomcat within BuildConfig.groovy to configure Tomcat, this would only work for development and testing environments and not production.
Thus, it's best to use install-templates and modify your src/templates/war/web.xml to have the correct value for the httpOnly attribute. e.g. <Context httpOnly="false" ... You can find out more information about configuring Tomcat from their official documentation.
Related
We have a Vaadin Flow 14.x enterprise app and a recent security review highlighted the lack of HttpOnly flag being set with the JSESSIONID cookie. How do we set this flag with Vaadin Flow 14? I've searched quite a bit and have not found any references to this.
Our app uses embedded jetty, but that probably doesn't matter in this case as its Vaadin that's setting JSESSIONID from what we can tell.
SOLUTION
The solution as described below is to configure embedded jetty to set HttpOnly. In my case I did this via:
WebAppContext context = new WebAppContext();
context.getSessionHandler().setHttpOnly(true);
The key is to configure this through Jetty. Vaadin is just using javax.servlet.http.HttpSession without directly touching any low-level session management details such as cookies.
I have a Spring-WS web service (SOAP 1.2 MTOM) deployed as part of a large application (on Weblogic) returning incorrect Content-Type (Consumer doesn't like it). The Content-Type is
Content-Type: multipart/related;boundary="----=_Part_1_4569975.1498510764791";type="text/xml";start="<soapPart>"
I have another lean model service that I have deployed on TomEE returning it this way (Consumer likes it) -
Content-Type: Multipart/Related; boundary="----=_Part_4_1924421953.1498510734751"; type="application/xop+xml"; start-info="application/soap+xml"
What could be wrong on the first service. Where is the configuration that ensures the right Content-Type?
Update (after 5 days) -
I have narrowed it down to the same exact WAR file returning content-type "text/xml" on Weblogic (10.3.6) and "application/xop+xml" on TomEE 1.7.4. Anyone can tell me what could be the difference between these environments? How can I make the application return the right content type on Weblogic?
The difference between these two environments will be the SAAJ implementation. TomEE will likely use the one in the JRE, while Weblogic has its own SAAJ implementation. Instead of using Spring-WS with SAAJ, you may want to try configuring it with Axiom.
I have tried many ways to use the httponly flag to prevent XSS attack, but all failed.
Common way is to set use HttpOnly=true in context.xml
For test the result: in the java code set two test parameters in the cookie and in front jsp file include javascript to alert thedocument.cookie, the two test parameters set in java code are get and show in the alert.
Java code:
Cookie cookie = new Cookie("httponlytest","testsss");
response.addCookie(cookie);
Cookie cookie1 = new Cookie("testhttponly","successfu");
response.addCookie(cookie1);
javascript in jsp file:
alert("cookie------------"+document.cookie);
Is there anything i did wrong?
If you know how, it would be very helpful.
For others who do not know HttpOnly:
HttpOnly=true is a relative new attribute to make a cookie in the browser inaccessible to JavaScript.
So it is a browser-only security (XSS) technique to prevent accessing JSESSION_ID (hijacking java sessions) and such.
So you could always set the HttpOnly attribute in the Cookie itself. For the Java session ID it is now default I think, at least it should be.
<Context useHttpOnly="true">
This seems to work only for JSESSIONID. I just found this in SO.
Recently I was dealing with http-only=true cookies. During my research i found that Mozilla and Chrome do not allow java applets to use http-only=true cookies. I was getting issue in accessing the JsessionidSSO cookie. During my research on bugs of JAVA i found this bug
While in IE there is no issue in reading the cookies as IE has provided InternetGetCookieEx() API's to access http-only cookies and added the flag INTERNET_COOKIE_HTTPONLY available only IE8 and above versions. So the problem of accessing the http-only cookies still not solved as java proposed the fix in java 7 update 40 while the current version is java 7 update21.
My required setup is a (spring-security enabled) webapp that can either be pre-authenticated (using pubcookie) OR have a "dev" mode enabled so I can ignore pubcookie and show a login form. Naturally, dev-mode will be turned-off in production, where the app will sit behind an Apache running mod_pubcookie, but for dev/QA I don't really need the external authentication mechanism.
The login form should appear only if (1) there's no REMOTE_USER request header (meaning we didn't go through pubcookie); AND (2) dev-mode is turned on in a property file.
My question: can this be configured in the spring security XML file, or do I need to take this into the code? (and how do I do that?)
Thanks,
D.
You can write your own custom filter and specify that it in your security context. As it is your custom filter you can get request object as well as configuration from properties file.
if you found REMOTE_USER and dev-mode on then set authentication in security context holder.
for implementing custom filter refer to link
Ok, so what I did was using Spring Profiles to create two separate profiles for "dev" and "prod", where I used different http and authentication-manager elements.
This blog entry from springsource helped a lot:
http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/
Just pay attention to where he says you can declare a profile in the dispatcher servlet's init-param element - that didn't work for me, so I used the global context-param in web.xml to declare my profile:
<context-param>
<param-name>spring.profiles.active</param-name>
<param-value>dev</param-value>
</context-param>
D.
Grails 2.0 changed with the way it uses grails.serverURL for development and test environments (as described in the manual). However, I've had several problems with serverURL in regard to production deployment on Tomcat. There seem to be several options for serverURL (production mode):
(Added) this setting is just "smoke and mirrors", because Tomcat and Jetty have methods to control how the URL is handled for the App, down to the "App" level.
Use it to specify the server (as is pointed out as a "TODO" in Config.groovy)
Don't use it as indicated here by one of the Grails contributors, i.e. "It should always be safe to remove the serverURL property and let Grails generate urls relative to the current running app." It's not clear if this extends to production or not (when not generating emails).
Use another method instead, namely grails.app.context, which is not documented in Grails 2.0 manual, but is described in certain references, here and here.
Can you please clarify the correct use of serverURL and app.context, both for Jetty and Tomcat (production mode)?
Thanks
Good question! I was just looking for the correct way to get the actual serverURL without explicitly needing to configure it in Config.groovy (in a Grails 2.1 application).
Since Grails 2.0, there is a super-useful class called LinkGenerator that you can use virtually anywhere, for example in a Service:
import org.codehaus.groovy.grails.web.mapping.LinkGenerator
Class MyService {
LinkGenerator grailsLinkGenerator
String serverUrl() {
// Generate: http://localhost:8080/link-generator
grailsLinkGenerator.serverBaseURL
}
}
Thanks to Mr. Haki for blogging about this!
So the basic idea of the grails.serverURL configuration parameter is to allow the createLink method to know what URL you want when creating absolute links. If no grails.serverURL configuration parameter is specified, it will default to http://localhost:8080 (unless server.port is specified, then 8080 will be whatever) ...
The application context tells Jetty/Tomcat to run the application in a different root. For example, specifying
grails.app.context="/myApp"
will set your application root to "/myApp". In production mode, the application context is handled by the web container and this directive is ignored. The choice to configure your production jetty or tomcat instances to run your application in a different context is entirely dependent on what your technical requirements are.
So the real thing to consider is, in your application are you creating a lot of absolute links in your GSPs where you need to define a "production" serverURL? If not, then you don't need to specify it; if you are, then you'll need to specify it.
As a personal preference, the first thing that I always do after creating a new grails project is go into the config and change the grails.app.context to "/" ... It makes mirroring a production environment much easier for me.
Hope this clears things up!