nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

iwproxy_failover_remap problems in TS 6.5

Grundy

Hi all,
I'm trying to debug a proxy remap setting which works fine on our production server (TS 6.1 sp2 on Windows Server 2000 sp4), but not on a development server (TS 6.5 sp1 and LiveSite 2.1 on Windows Server 2003 EE). Obviously, there are major differences between the two environments, but I'm lost as to what in particular would affect the backward compatibility of this setting.

Here are the specifics:


[iwproxy_failover_remap]
_maxfail=1
_regex=/main/Intranet/.*/(WORKAREA/[^/]+|STAGING)/(.*)=/iw-mount/default/main/Intranet/STAGING/$2

Essentially this says that if I'm in a subbranch of Intranet and request a file which cannot be found in the current area, look for it in STAGING of the parent Intranet branch. I know the regex is valid since it works as designed in production.

Details on what I'm seeing:
I have a page (plain old HTML, not a LiveSite page) in child branch of Intranet which uses several images. Typically some image files would be maintained in the child branch, some in the parent, with the failover setting allowing the page to render both when previewed from the child branch. So...

1) action/scenario: preview page in child branch, having copied all images into the same workarea
result: works fine, as expected

2) action/scenario: preview same page in parent branch STAGING, having copied it from the child branch and submitted, with all images present there as well
result: works fine, as expected

3) action/scenario: delete some of the images from the child branch, then preview there again to test the failover remap
result: browser asks for username and password several times, after which the page displays, but images which should have been remapped are missing.

Due to the authentication request, this would appear to be a problem with permissions on the parent branch -- but then why was I able to view the page in the parent branch (step 2) with no problem? It only occurs when the remap is brought into play.

Any ideas?

Thanks,
Nutt

Find more posts tagged with

Comments

JonathonG

This seems a bit strange....wonder if something weird is happening with the initial part of the URL when you do your re-map. Maybe try:

_regex=(.*)/main/Intranet/.*/(WORKAREA/[^/]+|STAGING)/(.*)=$1/main/Intranet/STAGING/$2

That way you can be sure the remapped URL has the same initial string. I'm wondering if the browser (or TeamSite) thinks you've changed machines or something.

Jonathon
Interwoven Developer
Allstate, Inc.

Grundy

I agree, very strange.
Still getting same result with your changes in place.
Nevertheless, thanks for the suggestion!

JonathonG

Have you tried running proxy in debug mode to see what is happening to the URL? Maybe that would give some clue.

Jonathon
Interwoven Developer
Allstate, Inc.

Grundy

Yes, I have. From what I can make of the output, the URL is being remapped correctly. That leads me to think it's strictly a permissions problem -- except of course that as I mentioned before, I can view the images in the parent branch if I go there directly.

Good suggestion, though. Any other thoughts?

JonathonG

is the server name in the URL staying exactly the same? What I'm driving at is that its possible that after remap the server name gets expanded to full DNS name or shortened or something like that. Then, your cookie is not valid for the redirected location. Maybe post the iwproxy -d results as an attachment?

Jonathon
Interwoven Developer
Allstate, Inc.

Migrateduser

Considering it might be a permissions issue... does the TeamSite Preview Group have access to the content you want to display?

Grundy

Ok, I've captured output from iwproxy -d and iwproxy -x. In both cases I simply tried to hit one of the images in question, rather than the whole page. The result in the browser was roughly the same -- I'd get prompted for authentication multiple times, then ultimately have a 401 error returned (despite entering the same username and password that I am already logged into TeamSite with).

iwproxy -d results are attached here; I'll do another post with iwproxy -x results momentarily since it appears we can only do one at a time.

Grundy

iwproxy -x results for same experiment as previous post

Grundy

Yeah, I've checked permissions repeatedly in both areas, and even experimented with alternate remappings which point do a different directory in the same workarea as the original request. TeamSite Preview Group has access throughout the site, and previewing in any of these areas works fine, just as long as no remap is involved.

Thanks for the suggestion, though.

JonathonG

Hmm...nothing obvious here....Unfortunately, I don't have a server that I can play around with proxy on to try and reproduce your scenario, so I'll take a few more shots in the dark:

What kind of webserver is configured at teamsite.ebatrd.local:81? For some reason, this webserver is what is returning the 401 code. It appears to be returning that code for both attempts to access the file, both in the child branch and in the failover spot. I would have expected it to give a 404 in the child branch. What does iwproxy -d look like in the case where you access the parent branch file directly?

I see this text in the output: "Access control not enabled in iwproxy_access_control_enabled for url" I don't know what that means, but since this appears to be some kind of permissioning problem, maybe that message is important. Anyone else know what that message means?

Jonathon
Interwoven Developer
Allstate, Inc.

Grundy

The web server is IIS 6.0. I allowed tspostreboot.pl to configure the default website following the TeamSite installation, but apart from that none of the default configuration has been altered. The entire site is configured to allow anonymous access, or to use Windows' integrated authentication if access is restricted by ACLs. But even that shouldn't come into play because ACLs on all of my content allow for full control by the TeamSite Web Preview group, of which the anonymous access account is a member. In other words, it's a completely out-of-the-box configuration except for that one proxy remapping!

The only unusual thing that happened during installation was that I got prompted for a password for the anonymous access account, probably because Windows 2003 will not allow creation of an account with a blank password. (I've installed TeamSite 6.5 under Windows 2000 before, and did not have to bother with this.)

As for the iwproxy_access_control_enabled message, I had noticed that too and looked it up in the admin guide. From what I can make of the documentation, "Access control not enabled" means that any TeamSite user can view any content, which is the default setting. One can change this via iw.cfg to enable control for all content or for selected areas, but any change from the default would make it more restrictive.

sample_report.rptdesign

Grundy

Slight correction to my previous post: the integrated Windows authentication applies at the level of the iw-mount virtual directory, not the entire site.

I don't believe this makes a difference for the issue, but just in case...

reddyl

Are the MIME types for IIS set or not, probally this might be causing the issue.

~ reddy

Grundy

I still have the default MIME types in place -- relevant settings for the files I'm working with are:

.html => text/html
.gif => image/gif

Far as I know, the TeamSite installation doesn't change these (nor should it). Is that your understanding too?

reddyl

I dont think TeamSite installation updates the MIME types for customer webserver. Starting with IIS 6.0 version microsoft does not set the MIME type during the installation of the webserver, so you need to add them unless you have already done so. That was my understanding but I might be worng.

~ reddy

Grundy

Oh ok -- that explains where your question is coming from Smiley Happy

But somehow they've been set up here without me having to do it manually, so either the IIS or TeamSite installation must have set them automatically. Thanks for the suggestion, though.

JonathonG

Could you post the results from this question I asked earlier?

What does iwproxy -d look like in the case where you access the parent branch file directly?

You posted results from trying to access the image directly in the child branch. I'd like to see what happens when you try to access the image directly in the parent branch.

EDIT: Another thought. What happens when you try to access a file in the child branch that has never existed there, but does exist in the parent branch? I'm wondering if the fact that these files are "deleted" is causing the 401 from the child branch, and somehow that 401 is "getting stuck" on the redirect to the parent branch. I know, it's a stretch, but as we've both acknowledged, this is a weird situation.

Jonathon
Interwoven Developer
Allstate, Inc.

Edited by JonathonG on 01/19/06 03:36 PM (server time).

Grundy

Here are the iwproxy -d results when viewing the image directly from the parent branch; and thanks for the reminder about that!

Also, I tried your suggestion about trying to view a file from child branch which has never existed there, but does exist in the parent branch -- same result as prior experiments with files being deleted from the child.

I then keyed in the URL for a file which has never existed in either branch:
- from parent branch, this yields the expected 404
- but from child branch, I still get the repeated authentication challenges followed by 401

Yes, quite unusual.

JonathonG

Ok, I'm even more confused now. Why does this output have 401 in it first, and then a 200? Is it possible that the IIS instance has some kind of IP authentication set up? So, in the non-remapped case, it looks like the request is coming from your machine, but in the remapped case, its coming from the proxy, and that is disallowed? I know you've said you checked your security settings, but that's all I can think of. Otherwise, I have to give the dreaded "Have you opened a support case?" response.

Jonathon
Interwoven Developer
Allstate, Inc.

Grundy

Yep, that confused me too. Furthermore, I'm confused as to why having a remap in play should make a difference, since even requests that aren't explicitly remapped go through the proxy for workarea virtualization and so forth.

The security settings I checked before were just user permissions, so you may be on to something with the IP authentication. I'm going to go through IIS settings with a fine-toothed comb once more and then open a support case.

Either way, I'll post results back to the group. Thanks Jonathon for your help so far!

Grundy

Found the answer at last!

https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=49749

It turns out the steps for enabling asp.net are also needed for classic asp and for the failover remaps (even when the files being remapped contain no scripting). The KB article doesn't mention remaps at all, but after applying the steps, everything works!