[hu_smare.htm]: A small research into SIRS researcher database accesses
by ~S~ Humphrey P
provoked :-) @ [Ebenezer's board]
published @ [searchlores.org] in June 2000
[Back to Special Databases]

..... C U T . H E R E .......
> Did you managed to reach
> http://web7.infotrac.galegroup.com/itw/infomark/822/368/65056060w3/purl=rc1_SIRS_0_BK93390&dyn=5% 21xrn_15_0_BK93390?sw_aep=aacpl_itweb
> I did not try hard and I did not succeed yet. I
> guess it's related with AtGuard.

You mean, I'm not the only one who wonders at the offered open door?

Here's the scoop. The ordinary way the thing works... no, I'll tell it on the board... no, I'll tell it quick here in this e-mail, and then on the board.

You key in that URL and you come up with a form page for sw_aep=aacpl_itweb. (So, us proxy users are being rejected for that session, but allowed to put in our own library card number and go on with our own session.)

If you want to see all the libraries subscribing to infotrak.galegroup.com then do:
Boolean Search: [host:infotrac.galegroup.com]
Sort by: [library]

Many of them want more than just a Library Card Number. For instance, they might want you to be 'onsite' or want you to use a proxy, which they might host, or they might fake (and tie to an onsite email address and password.) But all verification schemes finally have to pass the password/librarycard verification test which infotrac hosts as a CGI named for your abbreviation.

So, the thing neat about this one, is that
  1. you don't have to be 'onsite' and
  2. any eight digit number seems to work for Library Card Number. (even a 4 letter word worked)
Next, infotrac.galegroup.com decides which server is going to serve you (web1 ... 7?), and starts sending you cookies. Total of six cookies.


the /650nnnnnw3/ is related to a 9-digit time-date stamp number.
the /nnn/nnn/ is tried, and then a different /nnn/nnn/ is finally decided upon. The whole thing is sort of a routing and session number.

I'm surprised we are getting along with /822/368/65056060w3/ days later. Must stick out like a sore thumb in the logs.

The SIRS_0_BK93390 is the database and the book number/document number.

They seem to be keeping track of your pages at dyn=5!...

When I found the lady's essay, I was at dyn=4!... Apparently I went right to the search, and found her one page quicker than fravia did. dyn= might mean dynamic page. And the xrn_15 equates to rc1-SIRS... probably rc1-SIRS is the real database address, and xrn_15 is the cached address... (Get you out of the bookshelves and seated at your table, and they will bring to you and surround you with your books... Don't want you wandering around, cluttering up the aisles.)

Your @guard bats down cookies, doesn't it?

I got it to work with cookies. And any-8-digit password. (At other sites, your mileage may vary. - (that means, you won't be so lucky: 13 digits, barcode crc, onsite requirements, proxy tricks))

Now, dummy that I am... The whole point of this seems to be to bypass the cookies... and the library password verification and the whole fancy fussy front end altogether, and just use the database.

I didn't get that to work, either. I see it, but I can't get there... The mean farmer curse: "Cain't get there from here."

So, your tricks were:
Note that .gov and .mil and .edu might restrict access to their sites to those domains.
So, find a proxy which looks like they do. A proxy at their site, might be best.

But, we are collecting more tricks...
If this database server works without cookies, it's kind of like the programmer's back door...

And there must be ways to find out e-mail and password equations for graduating students.... perhaps even learn the three finger salute, which makes everyone presume you are qualified, so that your credentials aren't even looked at.


I'm going to print this on the messageboard... so everybody can feel good about being way ahead of me... of us... OK?

...... C U T . H E R E .....

[Back to Special Databases]