ceoconsultancy
asked on
Allowing Multiple HTTPS Sessions Within The Same Browser Session
Hi there,
I have two seperate webapps running on HTTPS protocol (listening on port 443) using 2 different certicates.
When users access the first HTTPS webapp the browser will prompt them to accept the certificate once, their sessions will be valid throughout the pages in the same webapp. But then when I try to portforward them to another HTTPS webapp through another port, let's say 9800, within the same IP, the second webapp page will prompt the user to accept the new certificate of it (which it should) and then the session of the first webapp will no longer be valid. (The session id has changed).
To make things clear here's the portforwarding process:
https://mymachineip:443/webapp1
to
https://mymachineip:9800/webapp2
I use javascript window.open to open a new window for the second webapp, while maintaing the 1st webapp page in the old browser window (because some services are still needed). My main question is, can I create a brand new session for the HTTPS page? I have seen some old threads posted here but the solutions do not apply successfully to the HTTPS webapp. FYI if both HTTPS Webapps use the same cert then no problem will occur. It works well too if both webapps are HTTP protocol.
Any advice from the experts would be helpful. Maybe some workarounds too. Thanks in advance.
I have two seperate webapps running on HTTPS protocol (listening on port 443) using 2 different certicates.
When users access the first HTTPS webapp the browser will prompt them to accept the certificate once, their sessions will be valid throughout the pages in the same webapp. But then when I try to portforward them to another HTTPS webapp through another port, let's say 9800, within the same IP, the second webapp page will prompt the user to accept the new certificate of it (which it should) and then the session of the first webapp will no longer be valid. (The session id has changed).
To make things clear here's the portforwarding process:
https://mymachineip:443/webapp1
to
https://mymachineip:9800/webapp2
I use javascript window.open to open a new window for the second webapp, while maintaing the 1st webapp page in the old browser window (because some services are still needed). My main question is, can I create a brand new session for the HTTPS page? I have seen some old threads posted here but the solutions do not apply successfully to the HTTPS webapp. FYI if both HTTPS Webapps use the same cert then no problem will occur. It works well too if both webapps are HTTP protocol.
Any advice from the experts would be helpful. Maybe some workarounds too. Thanks in advance.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Sorry YimYates that trick doesn't work, even if it does we do not want to educate the users to do it that way. (It's hard to educate non-computer-literate users). Anyway it does work if we use runtime to open a new window, but that's not what we want.
Yeah url rewriting could be a solution, but i need to clarify one thing before i proceed blindly to the implementation because it involves too many links to be encoded. I m not sure if it works with this https browser behavior:
Everytime user click yes to accept a new cert in the child window (2nd webapp), the session of both parent and child window changes (and will be invalidated). And then user switches back to the parent window and tries to access other links, he/she will be prompted to accept the cert for the parent window again (1st webapp), and thus causing the session to change again. In short, switching the access between the 2 windows will constantly prompt the users to accept the certificates of one another (This might annoy them), and refresh the window session as well.
How could url rewritting work with this situation? I believe dropping the jsessionid alone wouldn't be sufficient. The session refreshes too frequently. Any solution for this?
FYI even if we force the users to install the certificate the IE still prompt user for ack before it loads the page....
Another quick question: Any security concern if we have both webapps sharing the same certificate? Thanks in advance!
Yeah url rewriting could be a solution, but i need to clarify one thing before i proceed blindly to the implementation because it involves too many links to be encoded. I m not sure if it works with this https browser behavior:
Everytime user click yes to accept a new cert in the child window (2nd webapp), the session of both parent and child window changes (and will be invalidated). And then user switches back to the parent window and tries to access other links, he/she will be prompted to accept the cert for the parent window again (1st webapp), and thus causing the session to change again. In short, switching the access between the 2 windows will constantly prompt the users to accept the certificates of one another (This might annoy them), and refresh the window session as well.
How could url rewritting work with this situation? I believe dropping the jsessionid alone wouldn't be sufficient. The session refreshes too frequently. Any solution for this?
FYI even if we force the users to install the certificate the IE still prompt user for ack before it loads the page....
Another quick question: Any security concern if we have both webapps sharing the same certificate? Thanks in advance!
>>Yeah url rewriting could be a solution
Not sure if it was a solution but I proposed a possible one.
Not sure if it was a solution but I proposed a possible one.
As long as "YimYates" has no objections ;-)
I asked him, and he said it was fine ;-)
hehehe
hehehe
You're such a "dag"!
You can try:
1. Start Internet Explorer, then choose Tools | Internet Options
2. Change to Advanced tab
3. In the list, under Browsing node unselect Reuse windows for launching shortcuts checkbox
4. Press OK