I am playing with VAST 8.6 and its latest Glorp port on VA Smalltalk. So far, I like what I see, even if Glorp still has glitches that I am currently working on with the Instantiations Support team.
One thing that made me scratch my head was my unability to login to a database more than once. Every time I tried to login to the DB a second time I’d get a security error from DB2.
Looking a bit deeper, I dug into how I set up the login information during image startup and made sure the connection parameters were correct. They were. Until after the first login. After I had logged in to the db, the Login instance I keep in a class variable would always contain nil in its #password variable.
I tried setting a breakpoint in Login>>#password: to find out who destroys passwords in my system. It turned out that nobody ever sets the password other than my startup code.
So next step: who is writing the variable. And it turns out the latest Glorp version does the following in the password getter:
password "Return the password for this login. If we are in a secure mode, then erase the password as soon as it is accessed." | returnValue | returnValue := password. secure ifTrue: [password := nil]. ^returnValue
So guess what Login>>#initialize does 😉
If you answered “it sets #secure to true”, you get a full 100 credits.
So this is more or less another useless post of mine just documenting another one of these little stumbling blocks that seem to be strange but turn out to be easy to jump over. I hope, however, that this hint is useful to people who just start using Glorp or one of its later versions.
If Login forgets your password, set its #secure to false, or don’t reuse a Login instance. The latter alternative, however, requires you to store the password somewhere else, which may not be much more secure than the first one.
I must admit I miss the point about this security improvement in Glorp. So I’ll go with the first approach and simply store the password in this Login instance and set #secure to false.