• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Unique ids
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

d å√Uı&nâ€%a 1>·kÃ’

My esthetic soul is not satisfied ;-)

gt

P.S. Compared it with the much more civilized SessionID...

On Wednesday, May 14, 2003, at 20:22 Europe/Amsterdam, Art Isbell wrote:

If I recall, NSProcessInfo could provide a globally unique string by concatenating the host name, process ID, and a time stamp. In a multithreaded WO app on a multiprocessor computer, it is theoretically possible that more than one session could create identical strings using this approach. EOTemporaryGlobalID uses 3 similar values plus a sequence number that should ensure uniqueness, so this should be better. But since it is comprised of similar values to those used by NSProcessInfo, is it really uglier?

-- georg --

"More Trees, less Bushes!"
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Unique ids (From: Georg Tuparev <email@hidden>)

  • Prev by Date: Re: Attempt to insert null key into a com.webobjects.foundation.NSMutableDictionary
  • Next by Date: jar utility
  • Previous by thread: Re: Unique ids
  • Next by thread: (errata): NSDates, NSTimestamps and the Java-bridge
  • Index(es):
    • Date
    • Thread