[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]
Sunitha Kambhampati updated DERBY-1080:
---------------------------------------
Attachment: derby1080.2.diff.txt
derby1080.2.stat.txt
I am attaching a patch for Bryan's comments in
http://www.nabble.com/Re%3A-jira-Updated%3A-%28DERBY-1080%29-Connection-reset-when-using-security-mechanism%3DEUSRIDPWD-results-in-protocol-error.-p3293695.html
Thanks Bryan and Kathey for looking at this patch.
This patch (Derby1080.2.diff.txt) makes the following change compared to
previous Derby1080.diff.txt.
1) Reset of database.decryptedUserId and decryptedPassword is moved from
DRDAConnThread to Database.reset(). Note: that these 2 variables were not
correctly reset for connection-reuse which was causing the problem mentioned in
this jira. This patch adds reset() method in Database and resets the above 2
variable and also resets the variables related to security mechanism only.
I talked to Kathey on IRC about this:
-- the above change fixes this particular problem in this issue.
-- But more investigation is required for database reset when connection
pooling and transaction pooling is done.
-- File a jira so the reset cleanup can be done after investigation.
Does this sound reasonable ?
2) I have reorganized the regression test and added lots of comments. I hope
they are helpful in understanding the expected results.
3) Bryan asked"Lastly, would your test have been any different if you had used
ConnectionPoolDataSource.getPooledConnection(String user, String password)
rather than ConnectionPoolDataSource.getPooledConnection()? "
The result would be the same. For eusridpwd case, the client sends the
encrypted userid and password sectkns as part of SECCHK. The protocol error was
happening because we only read the 2 sectkns if the database.decryptedUserId ,
database.decryptedPassword is null, otherwise we think we have already read
this. Thus on a connection reset,if the decryptedUserId and decryptedPassword
are not reset, server assumes we have seen more SECTKN's and thus we throw
error too many codepoints.
Per the code: The userid/password passed in getPooledConnection will be the
user and password that is used. If userid and password is not set in
getPooledConnection, then the information is retrieved from the
ConnectionPoolDataSource.
svn stat:
code change
M java\drda\org\apache\derby\impl\drda\Database.java
M java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
test change
M
java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\testSecMec.java
master file for JCC2.4 driver and for IBM131, Sun JVM131,141,142,15.
M
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\testSecMec.out
master file for JCC2.6 driver and for IBM131, Sun JVM(versions 131,141,142,15)
M
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ver2.6\testSecMec.out
master file for JCC2.6 driver and for IBM (versions 141,142,15). Note these
jvms support the EUSRIDPWD security mechanism.
M
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\ver2.6\testSecMec.out
master file for JCC2.4 driver and for IBM(versions 141,142,15). Note these jvms
support the EUSRIDPWD security mechanism.
M
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\testSecMec.out
master file for client driver and for IBM131, Sun JVM (versions 131,141,142,15)
M
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\testSecMec.out
master file for client driver and for IBM jvm (versions 141,142,15)
M
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\ibm14\testSecMec.out
Test ran ok with derbynetclientmats and derbynet with ibm142 on linux with
known failures in surtest and stress.multi.
testSecMec.java was run with derby client, JCC2.4,JCC2.6 with
ibm131,ibm141,ibm142,ibm15,sun - jdk131,141,142,15 ok.
Please review this change. Thanks.
> Connection reset when using security mechanism=EUSRIDPWD results in protocol
> error.
> -----------------------------------------------------------------------------------
>
> Key: DERBY-1080
> URL: http://issues.apache.org/jira/browse/DERBY-1080
> Project: Derby
> Type: Bug
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0,
> 10.1.2.1, 10.1.2.2
> Reporter: Sunitha Kambhampati
> Assignee: Sunitha Kambhampati
> Fix For: 10.2.0.0
> Attachments: Derby1080.diff.txt, Derby1080.stat.txt, derby1080.2.diff.txt,
> derby1080.2.stat.txt
>
> if connection is reset, the security mechanism related information for
> EUSRIDPWD is not reset correctly and this leads to a protocol error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
