8 messages in org.apache.ibatis.user-javaRe: resultClass for BLOB field
FromSent OnAttachments
Karen KochDec 18, 2006 8:23 am 
Clinton BeginDec 18, 2006 8:46 am 
Karen KochDec 18, 2006 9:00 am 
Dave RodenbaughDec 18, 2006 9:02 am 
Clinton BeginDec 18, 2006 9:10 am 
Nathan MavesDec 18, 2006 10:23 am 
Karen KochDec 18, 2006 10:27 am 
Clinton BeginDec 18, 2006 8:51 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: resultClass for BLOB fieldActions
From:Karen Koch (kmk@sbcglobal.net)
Date:Dec 18, 2006 10:27:40 am
List:org.apache.ibatis.user-java

Yes, actually, I misspoke when I said I was decrypting the password. There are
times when other data that I'm encrypting has to be decrypted in order to
present it to the user (as in user-defined challenge question to confirm
identity in case they forgot their password) or to pass on to a third party (as
with credit card transaction processing), both over SSL, but I don't actually
bother to decrypt the password...

Thank you, though! Karen

Nathan Maves <nath@gmail.com> wrote: Just a thought but you might want
to think about never decrypting a password. I would just compare the two
encrypted version.

Just one extra safety step :)

On 12/18/06, Clinton Begin <clin@gmail.com> wrote: Sorry Karen, I messed up in my explanation. I didn't fully read your SQL or your
mapping.

You can't do it directly like that. This is one of the few (perhaps the only?)
type that iBATIS can't return directly. You'll need to create a class that has a
byte[] property, "Password" for example. Since you're doing a number of
operations for encryption and transformation from string to binary types, a
Password class might be useful anyway.

If you're in control of this database, I always recommend storing such things as
hex in a CHAR or VARCHAR field, rather than binary. That way you could just map
it to a string. It's way easier to deal with in every way, its no less secure
and it's probably faster.

If you're not in control of the database, you'll need to do as I suggested
above.

Cheers, Clinton

On 12/18/06, Karen Koch < kmk@sbcglobal.net> wrote:Re: your comments,
Clinton, the field is not huge, and I just want to grab a stored encrypted
password in order to decrypt it and compare to the user-entered password (part
of a login procedure).

Now, my latest problem: substituting "byte[]" in for the resultClass yields a
java.lang.ClassNotFoundException exception for byte[]. (I forgot to mention
having already attempted that.)

<select id="getEncryptedPassword" resultClass="byte[]" parameterClass="string"> SELECT Password FROM EPLoginAccount WHERE EmailAddr = #value#

Perhaps I'm not familiar with how to return an array from a statement. A bit of
help?

Thanks again, Karen

Clinton Begin <clin@gmail.com > wrote: Right. We don't make use of the
JDBC Blob/Clob classes. So you have to use a byte[] (byte array).

However, if your BLOB is huge, you might want to stream it directly to disk, or
even directly to the browser. In this case you'll want to bypass iBATIS, as it
likely doesn't make sense to map huge data structures to anything resident in
memory.

Cheers, Clinton

On 12/18/06, Karen Koch < kmk@sbcglobal.net> wrote: Hello --

I think this is a simple one: What is the proper resultClass to use when
returning only a single column (of BLOB type) as the result of a statement?
SqlMaps doesn't seem to like "BLOB".

<select id="getEncryptedPassword" resultClass=??? parameterClass="string"> SELECT Password FROM EPLoginAccount WHERE EmailAddr = #value# </select>