Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2033473 | 1.3.1 | Stanley Ho | P1 | Resolved | Fixed | 1.3.1 |
JDK-2033472 | 1.3.0_01 | Stanley Ho | P1 | Resolved | Fixed | 01 |
JDK-2033471 | 1.2.2_006 | Stanley Ho | P1 | Closed | Fixed | 006 |
Each user session is assigned a unique cookie generated by the PegaWEB
servlet. The servlet log file shows the value of the cookie in a message
similar to the one below:
Setting cookie to wclientnt$955719197495-5455746954853429210
This cookie is sent to the client with every transaction response.
When the user runs a workflow that invokes our applet, the applet issues a
request to the PegaWEB servlet. The plugin java console shows the request
being made and the cookie value in a message generated by the plugin
similar to the following:
Opening
http://wsolomnt3.pegasystems.com/action.pega?f990=GQUA&f991=GOPERAT%2F%4
0LIST&f992=&f993=&f994=&f900=955719334432808&%40FROM-FRAME=__pegMainFram
e&f996=y with cookie "PegaID=wclientnt$955719197495-5455746954853429210".
If the user terminates their session and then subsequently reconnects to
create a new one, they are assigned a new cookie, as shown below from the
servlet log file.
Setting cookie to wclientnt$955719435317-2254864088541347784
Remember, the user has not closed the browser application after terminating
session one and before starting session two. If they did, the problem
would not occur because the plugin is re-started.
When the same workflow is run, invoking the applet which submits a request
to the servlet, the plugin console shows the following message:
Opening
http://wsolomnt3.pegasystems.com/action.pega?f990=GQUA&f991=GOPERAT%2F%4
0LIST&f992=&f993=&f994=&f900=955719488814703&%40FROM-FRAME=__pegMainFram
e&f996=y with cookie "PegaID=wclientnt$955719197495-5455746954853429210".
As you can see, the cookie is the same value as from the original session,
not the second one, as it should be. We have no control (that we are aware
of) of the cookie value used by the plugin. Since the cookie value is
sensitive/secure information, it needs to remain in the cookie.
*** rkarpe 04/28/2000 ***
System Configuration:
Windows NT on both the client and server side
Using JDK 1.2.2_005 on both client and server
Java Plug-in 1.2.2
Client HW is usually a Gateway 2000
The problem occurs when using IIS, Netscape Enterprise Server 3.6,
Apache and with servlet environments New Atlanta ServletExec 2.x
and Allaire JRun.
The plugin is sending the wrong cookie, so the problem is in the
plugin, the supplied sample code exhibits the problem.
servlet. The servlet log file shows the value of the cookie in a message
similar to the one below:
Setting cookie to wclientnt$955719197495-5455746954853429210
This cookie is sent to the client with every transaction response.
When the user runs a workflow that invokes our applet, the applet issues a
request to the PegaWEB servlet. The plugin java console shows the request
being made and the cookie value in a message generated by the plugin
similar to the following:
Opening
http://wsolomnt3.pegasystems.com/action.pega?f990=GQUA&f991=GOPERAT%2F%4
0LIST&f992=&f993=&f994=&f900=955719334432808&%40FROM-FRAME=__pegMainFram
e&f996=y with cookie "PegaID=wclientnt$955719197495-5455746954853429210".
If the user terminates their session and then subsequently reconnects to
create a new one, they are assigned a new cookie, as shown below from the
servlet log file.
Setting cookie to wclientnt$955719435317-2254864088541347784
Remember, the user has not closed the browser application after terminating
session one and before starting session two. If they did, the problem
would not occur because the plugin is re-started.
When the same workflow is run, invoking the applet which submits a request
to the servlet, the plugin console shows the following message:
Opening
http://wsolomnt3.pegasystems.com/action.pega?f990=GQUA&f991=GOPERAT%2F%4
0LIST&f992=&f993=&f994=&f900=955719488814703&%40FROM-FRAME=__pegMainFram
e&f996=y with cookie "PegaID=wclientnt$955719197495-5455746954853429210".
As you can see, the cookie is the same value as from the original session,
not the second one, as it should be. We have no control (that we are aware
of) of the cookie value used by the plugin. Since the cookie value is
sensitive/secure information, it needs to remain in the cookie.
*** rkarpe 04/28/2000 ***
System Configuration:
Windows NT on both the client and server side
Using JDK 1.2.2_005 on both client and server
Java Plug-in 1.2.2
Client HW is usually a Gateway 2000
The problem occurs when using IIS, Netscape Enterprise Server 3.6,
Apache and with servlet environments New Atlanta ServletExec 2.x
and Allaire JRun.
The plugin is sending the wrong cookie, so the problem is in the
plugin, the supplied sample code exhibits the problem.
- backported by
-
JDK-2033472 Old value for cookie being used in new session
- Resolved
-
JDK-2033473 Old value for cookie being used in new session
- Resolved
-
JDK-2033471 Old value for cookie being used in new session
- Closed