[pmwiki-devel] Advice on coexisting with AuthUser?

john.rankin at affinity.co.nz john.rankin at affinity.co.nz
Sat Jul 26 18:11:14 CDT 2008


> On Fri, Jul 18, 2008 at 03:45:03PM +1200, John Rankin wrote:
Thanks for the reply.

>> Specifically, I'd like to understand what the PublishPDF library has
>> to do if a site has AuthUser enabled, so that the external PDF server
>> can request content from the wiki and get a response, instead of a
>> prompt for a username and password. When a user requests a PDF, this
>> causes the PDF server to issue an http request for the page content,
>> so we have to authenticate the PDF server as an authorised reader,
>> with the same rights as the person initiating the request.
>>
>> The user is already authenticated, so somehow that authentication
>> information needs to be supplied to the wiki, so it doesn't ask the
>> PDF server to log in. The PDF server doesn't know any user names or
>> passwords. Is there a session token I can pass from the user to the
>> PDF server, that it can pass on as part of a page request and so
>> inherit the user's read access rights?
>
> Here's my initial analysis--feel free to point out any errors:
>
> I think there's not an easy way to get the session token for an
> already-authenticated user, because (1) session tokens are tied
> to cookies, (2) cookies are tied to specific domains, and (3)
> the PDF server is at a different domain, so won't get the cookie
> from the browser.

Yes, I thought that might be the case.

> The most robust solution would be for the PDF server to
> ask the user for username and password and then pass those
> along in its http request to the wiki.  It could do this at
> the outset, or only when a request results in an authentication
> request from the wiki.

I had hoped to avoid this, if possible:
- the user will think "but I already signed in"
- we'd have to prompt for a name and password on each and
   every PDF request

But it is the easiest solution to implement.
>
> Another slightly trickier solution would be for the wiki
> to generate links and/or forms that are submitted to the
> PDF server that contain the needed session token information.
> In this case one would not be able to grab protected pages
> from the PDF server directly, but only via links or forms
> generated from the wiki.

Well. PDF requests are always initiated from a special form.
Donald Gordon did something clever with cookies to make
password protected pages work. He passed this to the
PDF server:

# pass authentication to wikipublisher
  if (isset($_COOKIE['PHPSESSID']))
      $out[] =  '<input type="hidden" name="PHPSESSID" '.
      'value="'.htmlspecialchars($_COOKIE['PHPSESSID'],ENT_QUOTES) . '" />';

Then the PDF server Perl script does this:

    my $req = HTTP::Request->new(GET => $url);
    $req->header('User-Agent' => 'Wikibook');
    foreach my $key (keys %{$opts->{cookies}}) {
	$req->header("Cookie" => $key."=".$opts->{cookies}->{$key});
    }

I don't understand this, but the PDF server can generate a
PDF from a password-protected page. I'm afraid I have no
idea whether a similar approach would work with AuthUser,
or what code it would need.
>
> Let me know if either of the above make sense and I can
> point out the PHP details needed to make it work.

The second option would be preferable, I think (although
"makes sense" would be going too far).

The third option I had been thinking about was a recipe
to let a privileged request bypass AuthUser, under certain
strict conditions:

1. the http request must come from a known IP address,
    so that local/config.php contains
        $AuthIP['wikibook'] = 'address.of.pdf.server';

2. the url must include some other token that gets
    verified; e.g.
** as part of the PDF request form, prompt the user to
    enter a randomly-generated 3 digit number
** include a codified version of this number as a hidden
    variable in the form
** the PDF server passes these on to the wiki server as
    part of its content request

3. if the incoming http request is from the authorised IP
    address *and* when we re-encode the supplied 3 digit
    number the result matches the hidden variable
** then *somehow* AuthUser allows the request (this is
    the bit I don't know how to do, or even if it's possible)

I use the 3 digit access code method to grant access to
the edit form on the open wikipublisher wiki, so the code
already exists.

The flaw in this approach is that the wiki would be unable
to enforce any user-specific access restrictions, as it
doesn't know which user originated the request. However,
it may be "good enough" in most situations, since we can
be confident the request originates from a page that the
user is authorised to access.

Thanks again and apologies for the long post.
JR






More information about the pmwiki-devel mailing list