Question
LANIT JSC
RU
Last activity: 26 Apr 2016 12:08 EDT
Can I rename the cookie JSESSIONID (PRPC7.1.8) ?
We have at the moment a very big project. Many systems operate on the same domain. One of these systems we open in an iframe. We have a conflict between the systems (PRPC and other). Both systems replace cookie JSESSIONID. Now we want to change the session name on the application server from JSESSIONID to PRWEB_JSESSIONID. But we do not know what impact this change to PRPC.
We were looking for full-text search, and found the following ruls, where it is referred to. After a quick analysis it was clear that some java scripts are used directly in the code "JSESSIONID". I think this is a terrible code.
Who can say how safe this change (rename JSESSIONID to PRWEB_JSESSIONID), and what can we expect?
Updated: 9 Feb 2016 8:05 EST
Pegasystems Inc.
US
Hi Nakita,
The JSESSIONID cookie is not part of PRPC. This cookie is part of and configured within the Application Server Level; WebSphere, WebLogic, Tomcat, JBOSS etc all provide a way for you to rename the JSESSIONID cookie. You need to consult your Application Server documentation on how to rename the cookie.
This is a very standard practice and will not affect PRPC processing.
--Chris
LANIT JSC
RU
Well, thanks for your reply.
I understand that you have written and I would not have problems if the full-text search was not the rules, which refers to the cookie JSESSIONID. It turns out that a number of scripts using the cookie JSESSIONID and rename it may have a negative impact on PRPC. Is not it?
Accepted Solution
Pegasystems Inc.
US
Nikita,
Sorry Nikita, jumped the gun on the reply.
Customers change the JSESSIONID cookie name all the time, it's very standard practice. We understand it can and will be changed.
Yes, there are some coded looks for JSESSIONID in two of the major UI level files mentioned above, PegaCompositeGadgetMgr.js and SafeURL.js. These do specifically look for JSESSIONID when URL encryption is on but has alternative processing and not because it could be renamed but more because it could be marked as HTTP only.
The XML files for word merge are for the older OCX control, not a concern.
The only one that is a concern is the pyWeb-login-mobile in the clearCookies function. That is just wrong and should not be coded like but probably doesn't have an affect on mobile logins either.
--Chris
LANIT JSC
RU
Chris,
Thank u!
But if I have a few questions.
1. What is 'URL encryption'? Did you mean Servlet mode when cookies are off?
2. What do you mean by 'marking JSESSIONID as HTTP only'?
3. How would this JavaScript work if cookies/URL parameter is named not JSESSIONID?
4. As for the script pyWeb-login-mobile. It turns out that it is necessary to create a service request for the correction of this code. Right?
Pegasystems Inc.
US
Hi Nikita,
1. What is 'URL encryption'?
This is an advanced security feature provided with PRPC that can be enabled so that all URL content is encrypted. The URL's are encrypted client side and then decrypted on the server side.
2. What do you mean by 'marking JSESSIONID as HTTP only'?
At the Application Server level you can mark the JSESSIONID as Secure and HTTPOnly. These are separate flags, one or both can be set at the same time, and are part of general HTTP Cookie handling that are used to enhance security.
Secure: Cookie is only passed from browser to server when using HTTPS protocol. (Makes it so you really can only access the site via HTTPS)
HTTPOnly: Cookie is not accessible via document.cookie.
You can, via PRPC system settings, enable these cookie flags for the Pega-RULES cookie as well.
3. How would this JavaScript work if cookies/URL parameter is named not JSESSIONID?
The general gist is we handle it and we are not relying on the JSESSIONID cookie or really any cookies by name for functionality because any of them could be marked as secure or renamed.
4. As for the script pyWeb-login-mobile. It turns out that it is necessary to create a service request for the correction of this code. Right?
Hi Nikita,
1. What is 'URL encryption'?
This is an advanced security feature provided with PRPC that can be enabled so that all URL content is encrypted. The URL's are encrypted client side and then decrypted on the server side.
2. What do you mean by 'marking JSESSIONID as HTTP only'?
At the Application Server level you can mark the JSESSIONID as Secure and HTTPOnly. These are separate flags, one or both can be set at the same time, and are part of general HTTP Cookie handling that are used to enhance security.
Secure: Cookie is only passed from browser to server when using HTTPS protocol. (Makes it so you really can only access the site via HTTPS)
HTTPOnly: Cookie is not accessible via document.cookie.
You can, via PRPC system settings, enable these cookie flags for the Pega-RULES cookie as well.
3. How would this JavaScript work if cookies/URL parameter is named not JSESSIONID?
The general gist is we handle it and we are not relying on the JSESSIONID cookie or really any cookies by name for functionality because any of them could be marked as secure or renamed.
4. As for the script pyWeb-login-mobile. It turns out that it is necessary to create a service request for the correction of this code. Right?
This should be changed but it's not something that would impact anything right now. The first step is to see if anything in mobile login is actually calling the clearCookies function, it might not be. I can just add an item to get this addressed by the mobile team in a later release if not already done.
--Chris
US
Chris,
Quick followup on this....we are looking at enabling the Secure option on the JSESSIONID cookie. Our system decrypts HTTPS at a proxy, so effectively pega will not receive a HTTPS connection and will not server a JSESSIONID.
Are there any impacts to Pega if JSESSIONID is not present?
Thanks!
-Jon Greger