1

I have a webserver publishing different services over the same SSL VirtualHost, the two most commonly used being PhpMyAdmin and Cacti. These (and others) use 'cookie' style authentication, asking user and password in an HTML form (thus not using HTTP Authentication).

Being on the same hostname, the Safari browser didn't manage too well stored passwords: if I login to one app with user foo, and then go to app two it would propose me user foo and its password in the login form. Changing just the username to bar used to be sufficient to let Safari autocomplete the correct password in its form field. Annoying, but I could live with it - usernames are short and easy to remember when compared to the passwords we use.

After the update to safari5 this seems to be no longer true: if I store in safari (actually user keychain on OSX) credentials for https://www.foobarbaz.com/app1 AND credentials for https://www.foobarbaz.com/app2 there seem to be no way for it to autocomplete both based on the url. Even editing the keychain to add the path (it will store only the hostname by default) does not help.

Is there anything I can do to let it work the way I want while still keeping everything on one hostname? Modifying anything server side is of course possible, but I can't switch apps to HTTP Auth (and not every one will support it anyway) to use different 'realms'.

Luke404
  • 5,708
  • 3
  • 44
  • 58
  • Do you get the behavior you want with other browsers? – tomjedrz Jun 14 '10 at 19:05
  • This sounds like a Superuser.com question. The behavior you're discussing is entirely client-side, not server-side. – Andy Lester Jun 14 '10 at 19:36
  • @tomjedrz, I'm trying to fix the issue server side if I can, before going out asking customers to change browser. @Andy, I was in doubt too. But I can modify the server side to play nice with clients like S5, the opposite being impossible, and that made me decide for SF. But I could be wrong nonetheless.. – Luke404 Jun 14 '10 at 19:41

2 Answers2

2

As I understand things, in an HTTP request URI, the host is everything between the scheme (i.e. http://) and the end of the top level domain (i.e. .com/), and everything to the right of the host is the request for the host to process.

The best solution to your problem is to use sub-domains .. https://app1.foobarbaz.com/ and https://app2.foobarbaz.com. You will need to put the sub-domains in the DNS zone for the foobarbaz.com domain, and configure virtual hosts on the web server to process the requests using /app1 and /app2. Apache and IIS can both do exactly what you need without having to reconfigure the applications. You will probably have to obtain (or create) new certificates for SSL to work without the browser security errors.

Apparently this is not allowed, per a (IMHO silly) organizational policy. The OP should work to get this policy changed, because it conflicts with how the internet works.

That said, another alternative is to modify each app to deploy a specific cookie for itself, and then to look through all returned cookies to find the one for itself. How that is done depends on the platform, and is a StackOverflow question.

Community
  • 1
tomjedrz
  • 5,964
  • 1
  • 15
  • 26
  • having different domains would have been an obvious fix, unfortunately it's not an option (per policy) – Luke404 Jun 14 '10 at 19:42
0

If you mean authentication using HTTP auth (as opposed to an HTML form), this works: You can make it work by setting different authentication realms along with the URL. Like this:

    <Location /abc/>
        AuthType Basic
        AuthName "Realm for ABC"
        AuthUserFile /var/www/html/domain.org/abc/.htpasswd
        require valid-user
    </Location>

    <Location /xxx/>
        AuthType Basic
        AuthName "Realm for XXX"
        AuthUserFile /var/www/html/domain.org/xxx/.htpasswd
        require valid-user
    </Location>

The interesting part is the AuthName. Safari then remembers/autocompletes the HTTP auth dialog per Realm and not only per Domain.

Community
  • 1
Paul
  • 1,890
  • 3
  • 18
  • 24