Tip for dealing with session IDs in URLs
Brian Armknecht gives this tip for dealing with session IDs in URLs:
The nucat command wasn't working because the URL required a session ID that changes periodically. The new version of the command visits the page, scrapes the new session ID, then includes it in the search URL. I think it's sort of a cool trick.http://nucat.library.northwestern.edu/cgi-bin/Pwebrecon.cgi?Search_Arg=%s&SL=None&Search_Code=GKEY&PID={scrape -tokens pid%3D %22 -dirs 0 0 -url http://nucat.library.northwestern.edu/}&CNT=25&HIST=1
posted by Jonathan at 10/08/2007 09:35:00 p.m.
5 Comments:
Hmmm, That is a cool idea but unnessisary in this case as the catalogue can handle the search without the sesssion parameters.
eg: http://nucat.library.northwestern.edu/cgi-bin/Pwebrecon.cgi?Search_Arg=Alphabet&SL=None&Search_Code=GKEY&CNT=25&HIST=1
Good to know - thanks James.
Some unrelated remarks from an interested newcomer: (I've read all the comments on your original blog, but not everything here, so please forgive if duplicates).
The biggest problem for a newbie is the multitude of commands. It's not necessarily that there are too many - but the question is, how do I find the ones that will be useful to me? Golden Eggs is too long, even Jeremy's pick is too long, I think. The problem is not having any classification system.
My first suggestion would be to have a new kernel command ("kernel" is already taken, but you could reclaim it), which would simply display all the kernel commands. For a budding command creator, it's interesting to know what the basic building blocks are.
A second idea is to not only check for command name duplicates, but for command url duplicates - that way if someone creates a command which already exists (this becomes increasingly likely with the increasing number of commands), they are at least warned. A slightly cleverer algorithm would detect similar commands and invite the user to check them out first.
I think the community approach is great. But can you imagine Wikipedia with just CR and no UD?! I'm not saying that you should introduct update and delete of commands (and logins, profiles, passwords - yeugh!), but my suggestion would be some kind of garbage collector. For instance, the 'uses' counter could have a corresponding 'unused' counter which is decremented (say) every week. Once one overtakes the other, the command gets deleted. Or maybe sent to some archive/purgatory.
One last related suggestion is introducing some kind of naming convention. This is an alternative to namespaces (which would make command names too long). I see that unfortunately (for this idea), punctuation is already allowed as command names. But, for instance, prefixing a command with a tilde (~) could mean "this is a test command, the garbage collector can delete it within a day". (I know that there is now a test option when creating a new command, but if you want to nest stuff, that's not so handy). Another handy convention would be to differentiate 'redirection'-style commands from 'function'-style commands (though I recognise that the distinction is pretty hazy). [As an aside, are those the only types of commands? It took me a while on arriving at YubNub to work out that it was anything other than a way of creating shortcuts to frequently-used sites.]
Last thing - "echo {g}" provokes a "Max number of substitutions reached". Not necessarily a bug, but a possible exploit if overused?
Thanks for your patience.
Hi Benjol - All super suggestions!
I should add, it's a good summary of the current pain points.
Post a Comment
<< Home