password protected http:// pages

[Funky Dung]

Some of the sites i want to add contribute functionality to are password
protected. Could this be why when i try use the connection wizard to define a
site it wont let me?

If so, this could be a massive problem since many of our sites require users
to type their password before entering a site.

The exact windows alert i get is:

[Q]Contribute cannot verify your connection information. Please contact your
administrator for assistance.[/Q]

The http:// and LAN mappings are correct my end so i imagine it's a contribute
2 limitation?

Any help greatfully received.

[ChrisRolfe]

It would depend on what type of password authentication your sites use. If it
is on a server/file permission level (which it sounds like) then you would have
to give read/write rights to the contibute user who is doing the authoring.

[Funky Dung]

Our sites have the server configured to automatically redirect the user to a
login page to enter their user id and password. Once the user has done this
they get redirected back to the page that they were originally looking for.

Contribute slips up here because it sees the login page as not being within
the site root (because it isn't) and thus can't match the http:// url with the
drive map. This means a connection cannot be setup using the wizard. Is there
another way to set up a connection without using the wizard? Since the user can
type their user id and password in the contribute browser mode and be
redirected to a page they can actually edit, once a connection has been made
they will be fine. The problem is in making the initial connection. The same
problem occurs when enabling contribute connectivity in dreamweaver. Because
Dreamweaver is also redirected to a login page, it cant make a connection.

I realise it's a pain but i cant get the organisation to change the security
system!

To see our password protection in operation, try to access this url:
[L=http://www.open.ac.uk/learning/index.cfm]http://www.open.ac.uk/learning/index
.cfm[/L]

As you will see, you don't end up at that URL! - you get redirected to the
login screen.

[Frodis]

Why do they refer users to a different site to make them log in? It seems it's
harder to do this than logging them in on the site they're going to use,
because that's where they need to have a session active.

Anyway, you might be able to get around this by putting a plain vanilla HTML
document in the application directory so you can set up the initial connection,
then it shouldn't matter if you get redirected. It will just tell you you can't
edit the login page, and you didn't want to do that anyway.