Re: Unique ids
Re: Unique ids
- Subject: Re: Unique ids
- From: David Aspinall <email@hidden>
- Date: Thu, 15 May 2003 10:29:24 -0400
I think maybe you are on the right track, the problem is the
URLEncoding of the binary data values from the EOTemporaryGlobalID.
Specifically the URL must be in ASCII chars
http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
Here is a little experiment. You can find OpenSource Base64 encoders
all over the web, so I am not including mine here.
String pid = "9866";
String ip = "192.168.0.1";
String uid = "davida";
String sessionkey = pid + ":" + ip + ":" + uid;
System.out.println("session key: " + sessionkey);
byte[] bytes = sessionkey.getBytes();
try
{
// compress the string to see if it helps
java.io.ByteArrayOutputStream baos = new
java.io.ByteArrayOutputStream();
java.util.zip.GZIPOutputStream zip = new java.util.zip.
GZIPOutputStream(baos);
zip.write(bytes, 0, bytes.length);
zip.close();
// Base64 the zip stream to get it URLEncoding friendly
java.io.ByteArrayInputStream ziped = new java.io.ByteArrayInputStream(
baos.toByteArray() );
java.io.ByteArrayOutputStream base64 = new
java.io.ByteArrayOutputStream();
ticoon.crypto.Base64.EncodeStream( ziped, base64 );
String base64zip = new String( base64.toByteArray() );
// straight up key on URL
System.out.println("URL Encoded : " +
URLEncoder.encode(sessionkey));
// simple URL encoded base 64
System.out.println("URL Encoded Base 64 : " +
URLEncoder.encode(ticoon.crypto.Base64.Encode(sessionkey)) );
// url encode the base64 from the zip stream
System.out.println("URL Encoded base 64.zip : " +
URLEncoder.encode(base64zip));
}
catch ( Exception e )
{
System.out.println( this.getClass().getName() + ".+method;() " +
e.getClass().getName() + ": " + e.getMessage() );
}
---------------------
the output look like this
session key: 9866:192.168.0.1:davida
URL Encoded : 9866:192.168.0.1:davida
URL Encoded Base 64: OTg2NjoxOTIuMTY4LjAuMTpkYXZpZGE=
URL Encoded zip :
H4sIAAAAAAAAALO0MDOzMrQ00jM0s9Az0DO0Skksy0xJBAClIo+MFwAAAA==
In this example the URLEncoded base 64 string is smaller than the zip,
but if the size of your key increases, the zip will make more of a
difference. Either way the objective is obviously to keep the URL as
small as possible, so you might want to look at using a cookie instead.
As a side note I once used this scheme to pass user credentials
(userid, target page, url expiry date ..) between 2 web applications
for single signon (or at least transparent signon). In my case the
whole URL was hidden from the user and never appeared in the location
field so size did not matter as much, but we ran into trouble when the
URL became over 2K in size (the spec limit is 4K).
You can still the the process id (in WebObjects 5.2 anyway) from the
application properties
[2003-05-15 09:59:30 EDT] <main> WOPort=8122
[2003-05-15 09:59:30 EDT] <main> com.webobjects.pid = 7582
Bottom line, I would suggest you let EOF generate keys however it sees
fit, and then zip,encode,cookie or whatever as necessary to shield the
user.
Oh I have yet another idea, if the keys do not have visual value, you
could use EOF to generate a sequence number (integer 1,2,3,4..) and
then use a message digest to generate a Unique string. The
disadvantage to this is the MD5 string is a ONE-WAY encryption, so I
usually only use it for passwords, but you could use it to generate a
unique 32 char string. This also has the advantage of not needing
URLEncoding, so what you see is what you get.
Example password
c2b03cd1e03fda616e4d78694133fc47
3bb43fc00590f2ac779e0e7f651b1ed1
217343c55bc475d0a02ad32efe4b0ba3
David
On Wednesday, May 14, 2003, at 04:38 PM, Georg Tuparev wrote:
Art,
Here is typical URL encoded string produced with EOTemporaryGlobalID.