sru xslt support

Odd,

Have you tried escaping the . in the URL (%2e I think)?

Matthew> -----Original Message-----

Have you tried escaping the . in the URL (%2e I think)?

Yes, that didn’t help either (sorry, I forgot to mention it).

Matthias

Ouch. That seems like a pretty serious – and at the same time trivial
– issue. How about changing the spec to use 1-0?

Bruce

Using ‘x-info-2-auth1-0-authenticationToken’ would work. Also, the
more simple ‘x-authenticationToken’ works, of course. Would be
interesting to hear if this works on other platforms and/or servers.

If this is a universal problem (and not only on my machine), then I’d
propose to go for a preliminary solution (like ‘x-authenticationToken’)
and update it as soon as possible.

Thanks, Matthias

Quoting RFC 1738 “Uniform Resource Locators (URL)”:

“only alphanumerics, the special characters “$-_.+!*’(),”, and
reserved characters used for their reserved purposes may be used
unencoded within a URL”

So unencoded use of dots in URLs should be fine. However, googling
for dot and URL encoding gives results like these:

“this is a variation of the common “dot dot” directory traversal
attack. Older Web servers were vulnerable to this attack because
the “…” directories in URLs allowed attackers to back out of the
web root directory. This allowed attackers to navigate the file
system or execute commands at will. IIS and most current Web
servers have incorporated security measures to prevent the “dot
dot” attack. These security measures deny all queries to URLs that
contain too many leading slashes or “…” characters.”

(taken from: http://xforce.iss.net/xforce/alerts/id/advise77)

Other found problems re dots in URLs:

“The Microsoft web-server in their ASP server-side scripts such
that a hacker could append a dot to the end of the URL in order to
read the script contents rather than executing the script.”

Not sure if these things could be connected to our problem. We’re not
using two dots in a row nor are we using a dot at the end of the URL.
Anyhow, its just smells as if dots in URLs are not that safe any more.

Matthias

Date: Fri, 10 Jun 2005 00:52:18 +0200
From: Matthias Steffens <@Matthias_Steffens>

Using ‘x-info-2-auth1-0-authenticationToken’ would work. Also, the
more simple ‘x-authenticationToken’ works, of course. Would be
interesting to hear if this works on other platforms and/or servers.

If this is a universal problem (and not only on my machine), then
I’d propose to go for a preliminary solution (like
‘x-authenticationToken’) and update it as soon as possible.

I would strongly recommend against using just “x-authenticationToken”:
the reason the key is specified the way it is is to prevent accidental
collisions. Otherwise you and another, unrelated, group might both
choose to use same-named extensions with different meanings.

If “.” really is a problem (and has anyone else seen this? If not,
could it be a problem your browser’s configuration?) then a
‘x-info-2-auth1-0-authenticationToken’ would be a much better interrim
solution.

/| ___________________________________________________________________
/o ) / Mike Taylor <@Mike_Taylor> http://www.miketaylor.org.uk
)v_/\ “Tell me what you eat, and I will tell you what you are” –
Anthelme Brillat-Savarin–
Listen to free demos of soundtrack music for film, TV and radio
http://www.pipedreaming.org.uk/soundtrack/

Date: Fri, 10 Jun 2005 00:52:18 +0200
From: Matthias Steffens <@Matthias_Steffens>

Using ‘x-info-2-auth1-0-authenticationToken’ would work. Also, the
more simple ‘x-authenticationToken’ works, of course. Would be
interesting to hear if this works on other platforms and/or servers.

If this is a universal problem (and not only on my machine), then
I’d propose to go for a preliminary solution (like
‘x-authenticationToken’) and update it as soon as possible.

I would strongly recommend against using just “x-authenticationToken”:
the reason the key is specified the way it is is to prevent accidental
collisions. Otherwise you and another, unrelated, group might both
choose to use same-named extensions with different meanings.

Ok, I see. Then let’s take ‘x-info-2-auth1-0-authenticationToken’ as
a preliminary solution.

If “.” really is a problem (and has anyone else seen this? If not,
could it be a problem your browser’s configuration?)

But then all of my browsers must have this config problem which seems
unlikely. Btw, in addition to my local Mac OSX server [Apache/1.3.33
(Darwin) PHP/5.0.4] I do get the same problem on Apache/2.0.53
(Linux/SUSE) PHP/4.3.10.

I’d appreciate if someone with access to a web server could test
this. If you’ve got a PHP-enabled web server please copy the script
below into a file and put it into your server’s root directory:

<?php if (isset($_REQUEST['x-info-2-auth1.0-authenticationToken'])) $authToken = $_REQUEST['x-info-2-auth1.0-authenticationToken']; else $authToken = "(empty)"; echo $authToken; ?>

Then, (assuming you named the script ‘sruParamTest.php’) call the
script from within your browser:

sruParamTest.php?x-info-2-auth1.0-authenticationToken=testvalue

If the ‘x-info-2-auth1.0-authenticationToken’ parameter gets read
successfully, you should see “testvalue” (or whatever string you’ve
passed in the URL) in your browser window, otherwise “(empty)”.

Would be also interesting to see if a Perl CGI script has the same
problem which may indicate that it’s a server problem and not related
to the processing language.

Thanks for your help,

Matthias

I’ve tracked this problem down to a behavioural feature of PHP. The . in
the parameter name gets translated to a _

This is so that the import_request_variables function can generate
legitimate variable names (and a . is not permissable in variable names
in PHP).

See the section labelled “Dots in incoming variable names” on this page:
http://uk.php.net/variables.external

So the following code will work:

    if (isset($_REQUEST['x-info-2-auth1_0-authenticationToken']))
            $authToken =

$_REQUEST[‘x-info-2-auth1_0-authenticationToken’];
else
$authToken = “(empty)”;

    echo $authToken;

i.e.

sruParamTest.php?x-info-2-auth1.0-authenticationToken=testvalue

Will return the required result.

A side effect is that

sruParamTest.php?x-info-2-auth1_0-authenticationToken=testvalue

Will also work (although strictly speaking shouldn’t), but I think we
can live with that.

Matthew

Thanks, Matthew, nice work. So I suggest that the right thing to do
is to use the correct authentication parameter, as specified in the
current version of the SRU documentation, and to check for the
underscore version in PHP.> Envelope-to: @Mike_Taylor

Doh. I’ve searched the PHP site but haven’t found this important bit
of information. Thanks!

So I’ll use

<sruParamTest.php?x-info-2-auth1.0-authenticationToken=testvalue>

for querying and

if (isset($_REQUEST[‘x-info-2-auth1_0-authenticationToken’]))

when reading the parameter in the PHP script.

Thanks a lot for tracking this down!

Matthias

Matthias – can you post a complete example url again, then? It should
be one where the query and validation portion would be the same for
different projects.

Bruce

So I’ll use

<sruParamTest.php?x-info-2-auth1.0-authenticationToken=testvalue>

for querying

Matthias – can you post a complete example url again, then?

Here’s an example for the guest user (‘user@refbase.net’) of our
institution’s database:

http://polaris.ipoe.uni-kiel.de/refs/sru.php?version=1.1&query=bib.citekey+any+Ackley1990SnowCover+Broecker1997Science+Granskog2004Baltic+Mock2002Hydrobiologia+Simstich2003MarMicropaleontol+Thomas2003SeaIce&x-info-2-auth1.0-authenticationToken=email=user@refbase.net

It will display the first 5 of 6 records found.

It should be one where the query and validation portion would be
the same for different projects.

I’m not really sure what you mean. The given cite keys will, of
course, only work for our institution’s database and the given user.

Matthias