Question

We're using TWiki behind a firewall, with pages only accessible to authenticated users from our subnet. Within a TWiki page I'm unable to INCLUDE the content from another similarly protected internal but non-Twiki URL due to the following authentication (unauthorized access) problem:

• You are not authorized to view this page
  You do not have permission to view this directory or page using the credentials you supplied.
  
  This is usually caused by a server-side script not sending the proper WWW-Authenticate header field. Using Active Server Pages scripting this is done by using the AddHeader method of the Response object to request that the client use a certain authentication method to access the resource.

INCLUDing a non-protected page works fine.

Does anyone have any suggestions as to how to overcome this?

• TWiki version: 01 Dec 2001
• Web server: IIS5
• Server OS: Win2K/SBS
• Web browser: IE5
• Client OS: Win2k

-- AndrewMould - 29 Jan 2002

Answer

I don't know if this will work, but have you tried:

%INCLUDE{"http://user:password@site.dom.ain/path/to/page"}%

to see if it will include the web page? This is what I am planning on for Including stuff from another web page.

If that works, you can prevent showing the user:password, by changing the % INCLUDE% variable handler to substitute the above for an interwiki type of reference like:

WEBSITE:/path/to/page

where WEBSITE is defined in the TWiki config file.

-- JohnRouillard - 30 Jan 2002

No that doesn't work. Additionally the problem (for me) with that approach is that the password is maintained in clear text in the topic. Actually I've already worked around it by allowing a "userid" param to the Warning: Can't find topic ""."" variable, and then looking up the userid's encoded username / password info from a config file to pass as a header in the HTTP GET request. Not ideal, but it works, and it removes the actual username / password info from view.

I also came up with a simple scheme to prevent TWiki reformatting the included web content which I should document in Codev I guess. Perhaps I should get this topic moved there, somehow?!

-- AndrewMould - 31 Jan 2002