I have a project on a 2.7.3 version of Scala Play framework. I need to address being able to set a cookie's Samesite value to 'None'. Currently in 2.7.3 you can only set to 'Lax' or 'Strict' via an enumeration. The ability to set the value to 'None' has been backported for 2.7.x but not yet released.
I need to address this now and can't wait for a future release. I am having a hard time figuring out how to accomplish setting a Cookie's Samesite value to 'None' within the given framework.
In order to modify the response result in a filter, I see I could call result.withCookie() which takes one or more play.api.mvc.cookie. I've tried to extend and modify play.api.mvc.cookie but the Samesite class is sealed abstract inside the Cookie class.
I thought I might be able to use an Essential Filter or an Action to modify the cookie right before the response goes out but don't see a way to get at an existing CSRF cookie or the Play_Session cookie and modify it.
Any ideas?
I think the workaround for this is probably to either use a proxy as #rowan_m mentions. Fortunately Lightbend got back to me and will be releasing their 2.8 version very soon - which I verified in the RC solved the issue using config settings: https://github.com/playframework/playframework/pull/9613#issuecomment-555305142
Related
I need to update a javaEE application (still in java 1.7) that provides a SOAP web service. And I'd like to disable the TIMESTAMP_CACHE that wss4j (v2.0.2) uses to control reply attacks. It creates too many files and the OS reaches the maximum open files allowed, repeatedly. The files start to appear, one for each request that has been made and are named in the following way:
wss4j%002etimestamp%002ecache-e%0058ga%0058l%0058%004b%0057g%004ah%0050w==.data
The documentation states that the TIMESTAMP_CACHE can be changed (or so I understand):
ConfigurationConstants.ENABLE_TIMESTAMP_CACHE ("enableTimestampCache"): Whether to cache Timestamp Created Strings (these are only cached in conjunction with a message Signature). The default value is "true".
I've found many examples to change some of these ConfigurationConstants when a client application creates the Call object. See an example to change the PASSWORD_TYPE constant:
Service service = new Service();
Call call = (Call) service.createCall();
...
call.setProperty(UsernameToken.PASSWORD_TYPE, WSConstants.PASSWORD_TEXT);
call.setProperty(WSHandlerConstants.USER,"werner");
However, my application is not on the client side but on the server side and I haven't found so far the way to change the ENABLE_TIMESTAMP_CACHE constant.
Any idea?
I couldn't find a way to disable the timestamp cache. However, the wss4j behaviour described above happened to be a bug that not only resulted in lots of open files but in lots of open threads. It has already been fixed in version 2.0.9. Upgrading to the "newer" version did the trick.
You can find here the discussion in full that drove to the bug discovery and here the fix in wss4j's jira
I am facing a cookies problem in my website , I am using Scala with Play Framework 2.2.0.
If user replaces cookies with another user's cookies it works there i want to stop that please give me any solution.I have changed and modify in application.conf file with all security but i did not get any effect in my application.
If there is any type of trick or logic behind it please tell me.
As shown in the documentation it is just a config change https://www.playframework.com/documentation/2.8.x/SettingsSession.
Note: problems with deserialization might occur.
I have an existing integration with Paypal using the java sdk. We're planning a production release, but we can't let it got to prod with the current log level of the sdk. It seems to be set to DEBUG and logs every request going/coming from Paypal. I guess there must be a parameter to add to the paypal_sdk_config.properties file, but I can't seem to guess it and documentation is inexistant on the matter.
Anyone has ever done this before?
We just discovered, going through the code source of the com.paypal.core.LoggingManager class, that the logger creation is not intuitive.
The logger name is always something like class for example: class com.paypal.core.APIService
It means that you cannot set the log level through this call
getLogger("com.paypal.core.APIService").setLevel(Level.WARNING);
To set the log level, you need to do that:
getLogger("class com.paypal.core.APIService").setLevel(Level.WARNING);
I just open an issue on the Paypal github repo for that strange behavior: https://github.com/paypal/sdk-core-java/issues/13
I'm developing a multilanguage application, and use routes with translated segments. For multilingual support I created special Multilingual plugin.
To use translated segments I need set translator for Zend_Controller_Router_Route before routes init. So only possible place for this in my plugin is routeStartup method, but there is one problem here - for determine right locale I need to use properties of request (Zend_Controller_Request_Abstract), like module, controller and action names, but they are not defined yet here in routeStartup method. They are already defined, for example, in routeShutdown - but I can't set translator for route there, because it have to be done before routes init.
So what can I do:
can I get request properties somehow in routeStartup
or can I re-setup translator later in routeShutdown
P.S: there is a question with exactly the same problem Zend_Controller_Router_Route: Could not find a translator, but proposed answers is not the option for me, because I can't just retrieve language code from url with Regex, I have much more complicated code to define right language code.
Thanks.
What about putting your code in preDispatch? That's what I personally do when I need to check if the person is logged in. Maybe you can move your code there too?
Symptoms:
PumaLocator is unusable, every findXXX-method returns empty results or throws an exception because nothing was found.
Analysis:
The problem seems that, due to the ICEfaces specific architecture, the method GenericPortlet.doView is invoked only for the first time the Portlet is loaded, and not for the following (AJAX) page updates, e.g. in case of a called ActionListener.
If I use PumaLocator inside the doView-method, everything works fine.
I tried the following attempts yet:
Get the PumaLocator in doView, put it into Session and use it later - didn't work
Get the RenderRequest in doView, put it into Session and use it later to get a PumaLocator by passing that request - didn't work
I would be very glad to have any hints. Thank you!
PUMA checks the authorization for results by using information found in the Context. You must add JavaEE security roles in the deployment descriptor for the AJAX backend servlets the ICEFaces uses. As a thumb of rule if request.getRemoteUser() and request.getUserPrincipal() return something besides null you know PUMA will work. Otherwise it will NOT work and that is intended behaviour.
Alternatively you can attempt to disable the security checks of PUMA like this.