Topic: i-bay outside network with password: https access only. Can I switch this off?

[judgej]

I'm not sure how or when this started, but when I try to connected to an i-bay with a password from outside the local network, it will only let me connect via a https connection, and not a http connection.

Over http, it still prompts for a login, but then tells me the login details are incorrect. The logfiles just tell me that authorisation was refused:

[Sat Nov 22 23:30:54 2008] [error] [client 123.45.67.89] invalid AuthExternal keyword (pwauth)

Over https, it all works fine.

I'm sure it did not used to do this, but I'm not sure when it started. Is this now the default bahaviour, or is it just me?

As I need to spell this out each time: I'm asking other forum users if this is happening to them, and not at this time raising a bug for the developers.

-- Jason

[cactus]

I'm not sure how or when this started, but when I try to connected to an i-bay with a password from outside the local network, it will only let me connect via a https connection, and not a http connection.

Over http, it still prompts for a login, but then tells me the login details are incorrect. The logfiles just tell me that authorisation was refused:

[Sat Nov 22 23:30:54 2008] [error] [client 123.45.67.89] invalid AuthExternal keyword (pwauth)

Over https, it all works fine.

I'm sure it did not used to do this, but I'm not sure when it started. Is this now the default bahaviour, or is it just me?

Password authentication is only possible over SSL protected http (otherwise password travel over the network unencrypted), so no. AFAIK this has been the default behavior for SME Server for at least the 7 tree.

As I need to spell this out each time: I'm asking other forum users if this is happening to them, and not at this time raising a bug for the developers.

Then I suggest you start phrasing your questions likewise. I suggest the next time you are requiring such information you start your request with such a statement, preferably not in bold.
And yes, you also will have to conform to the fact that the developers can and will not read all messages on the forums to hunt down issues. Apart from the forums being a lousy tool to document software changes, therefore you are asked (over and over again) to report problems in the bugtracker. If you want things changed I suggest you start doing so instead of ventilating like this.

[warren]

[Sat Nov 22 23:30:54 2008] [error] [client 123.45.67.89] invalid AuthExternal keyword (pwauth)

Try checking the httpd.conf file for the lines concerning the ibay that you are trying to access and see what is in the httpd.conf file :

eg

Code: [Select]

#------------------------------------------------------------

<Directory /home/e-smith/files/ibays/ubu/html>
    Options None
    Options +Indexes
    Options +Includes
    AllowOverride None
    order deny,allow
    deny from all
    allow from all
    AuthName "Something"
    AuthType Basic
    AuthExternal pwauth
    require user ubusa
    Satisfy all
</Directory>

I have ibays setup for access from the WAN requiring a password and do not have to access it via https.

Are their any custom templates maybe for the particular ibay. ( I have some that are customised to require only https connections ....

Code: [Select]

<Directory /home/e-smith/files/ibays/ubu/html>
SSLRequireSSL
........

[judgej]

Warren,

Thanks. Those lines are there in http.conf, and are triggering the basic authentication password prompt correctly in my web browser (with the correct name given too, both for SSL and non-SSL ports).

I have stripped out all lines in http.conf added in by the subversion module that I had installed, and the problem went away, so at least I can narrow it down to the module. I'll start adding lines back in now and see which one it is that is causing the strange behaviour. Just from inspection, I cannot see anything wrong with the subversion module configuration lines, so perhaps some constructs supplied are triggering some deeper Apache bug - not sure, but I'll report back and raise a bug once I find out.

-- Jason

[judgej]

Okay, it seems to be the line in red below:

Code: [Select]

<Location /svn_backups>
        DAV svn
        SVNPath /home/e-smith/files/repositories/svn_backups

        SVNAutoVersioning on

        ModMimeUsePathInfo off

        AuthName "Website backups"
        AuthType Basic
        [color=red]AuthExternal pwauth[/color]

        # Read access:
        #  Anonymous access
        <Limit GET PROPFIND OPTIONS REPORT>
            order deny,allow
            deny from all
            allow from 127.0.0.1 192.168.6.0/255.255.255.0
            Satisfy all
        </Limit>

        # Full access:
        #  User(s) : backups
        <LimitExcept GET PROPFIND OPTIONS REPORT>
            order deny,allow
            deny from all
            # Denying access:
            # SSL required, no access allowed without.
            Satisfy all
        </LimitExcept>
    </Location>
If I comment that line out, the authentication works. What I don't understand is how this location section (for subversion) affects other i-bays, but it seems that it does. Perhaps it is because the i-bays use 'directory' sections rather than 'location' sections, and require a slightly different syntax? No idea. As least I know what the line is, so can follow this up.

There are further clues here:

http://blog.innerewut.de/tags/pam

It seems that password authentication cannot be used within a <Location> directive in Apache 2.2, unless the external script definitions are included just before the closing </VirtualHost> tag, i.e.

Code: [Select]

  ...
  AddExternalAuth pwauth /usr/local/bin/pwauth
  SetExternalAuthMethod pwauth pipe
</VirtualHost>
That is probably the solution I am going to have to go for - repeating those two lines in every VirtualHost section. Commenting out the offending 'AuthExternal' lines will be no good, as the authentication will no longer work on the subversion repository.

But the mystery is still with me: why should entry affect any other i-bay? I guess 'Location' is not limited to any particular i-bay, so it applies to them all? Maybe not?

[judgej]

Bug raised, with fix that can be applied while waiting for an official patch:

http://bugs.contribs.org/show_bug.cgi?id=4933