Two DB with different hosts breaks auth on both

[Stephen Hill]

If I open one database, and it's:

INFO: Setting supercontainer base url to https://url.domain.com:443/SuperContainer/Files

And then I open a second database, and it's:

INFO: Setting supercontainer base url to https://url2.domain.com:443/SuperContainer/Files

I get the following when running SCGetInfo( ... ; "md5" ):

Apr 30, 2011 1:50:23 PM org.apache.commons.httpclient.HttpMethodDirector authenticateHost

WARNING: Required credentials not available for BASIC <any realm>@url2.domain.com:443

Apr 30, 2011 1:50:23 PM org.apache.commons.httpclient.HttpMethodDirector authenticateHost

WARNING: Preemptive authentication requested but no default credentials available

Apr 30, 2011 1:50:24 PM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme

INFO: basic authentication scheme selected

Apr 30, 2011 1:50:24 PM org.apache.commons.httpclient.HttpMethodDirector processWWWAuthChallenge

INFO: Failure authenticating with BASIC 'SuperContainer'@url2.domain.com:443

Apr 30, 2011 1:50:24 PM com.prosc.supercontainer.plugin.SCPluginModel setBaseUrl

INFO: Set supercontainer base url in 526 milliseconds

Any attempt to SCGetInfo (with a followup SCLastError) on either database results in:

CONFIG: === Executing plugin function SCGetInfo on thread main ===

Apr 30, 2011 1:50:36 PM org.apache.commons.httpclient.HttpMethodDirector authenticateHost

WARNING: Required credentials not available for BASIC <any realm>@url2.domain.com:443

Apr 30, 2011 1:50:36 PM org.apache.commons.httpclient.HttpMethodDirector authenticateHost

WARNING: Preemptive authentication requested but no default credentials available

Apr 30, 2011 1:50:36 PM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme

INFO: basic authentication scheme selected

Apr 30, 2011 1:50:36 PM org.apache.commons.httpclient.HttpMethodDirector processWWWAuthChallenge

INFO: Failure authenticating with BASIC 'SuperContainer'@url2.domain.com:443

Apr 30, 2011 1:50:36 PM com.prosc.fmkit.Plugin setLastError

SEVERE: PluginFunction PluginFunction{name='SCGetInfo', functionID=-8372, minArgs=1, maxArgs=-1} got an error with converted args [client_dir/employee/100/100380, [md5]]

com.prosc.supercontainer.plugin.InvalidCredentialsException: Invalid credentials!  The username and/or password passed to the SCSetBaseURL function are incorrect.

	at com.prosc.supercontainer.plugin.SCPluginModel.validateVersionAndResponseCode(SCPluginModel.java:513)

	at com.prosc.supercontainer.plugin.SCPluginModel.getResourceInfo(SCPluginModel.java:719)

	at com.prosc.supercontainer.plugin.SuperContainerPlugin.SCGetInfo(SuperContainerPlugin.java:240)

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

	at java.lang.reflect.Method.invoke(Unknown Source)

	at com.prosc.fmkit.StaticFunction.invoke(StaticFunction.java:230)

	at com.prosc.fmkit.Plugin.invokeFunction(Plugin.java:337)

	at com.prosc.fmkit.Plugin.invokeFunctionNoErrors(Plugin.java:318)

	at com.prosc.fmkit.PluginBridge$3.run(PluginBridge.java:1028)

	at com.prosc.fmkit.PluginBridge.runTask(PluginBridge.java:1237)

	at com.prosc.fmkit.PluginBridge.doFunction(PluginBridge.java:1042)

While the supercontainer server logs:

Apr 30, 2011 1:30:29 PM com.prosc.supercontainer.model.Configuration _isValidAuth

INFO: Login failed for 'null' (wrong username)

Should I then alter the second database to use the same url as the first, and call SCSetBaseURL with the same url as the initial database, both databases will run the SCGetInfo successfully to that first domain. Convert the second database back to the original different url reverts back to broken behavior.

In addition, the SCSetBaseURL failure does not result in an error return, it returns '1' as if successful.

This has come about as I'm attempting to migrate clients to a different domain in order to migrate the server from one machine to another. Although I don't think it affects the end users (they should only have one entry for their databases) it's become quite difficult to work with multiple databases while in transition. With one database using SSL and another not using SSL, there are some log complaints, but the SCGetInfo appears to work still.

Note that SCSetContainer and SCDownload seem to work in either situation sometimes. I haven't tested too many iterations yet, but I believe that they'll work if I tested it before the second SCSetBaseURL but break if it's a new attempt.

SC server and companion plugin 2.792

[Smef]

It looks like your SCSetBaseURL is failing with the error:

INFO: Failure authenticating with BASIC 'SuperContainer'@url2.domain.com:443

I'll look into why this is returning a 1 for you if it is failing and see if I can reproduce that, but I think that this is where the problem is. Make sure that you are using the correct username and password that you set on your SuperContaine server and that your Apache/IIS server is not requiring a username and password. The username and password that you set in SCSetBaseURL is for the SuperContainer Server UN/PW, not the IIS/Apache server. The plugin will not be able to communicate with SuperContainer if your web server is blocking traffic by requiring additional authentication information.

If you are having trouble with the scripting for this you may just want to copy the files from your old server to the new server using your network or an external hard drive.

[Stephen Hill]

It looks like your SCSetBaseURL is failing with the error:

INFO: Failure authenticating with BASIC 'SuperContainer'@url2.domain.com:443

I'll look into why this is returning a 1 for you if it is failing and see if I can reproduce that, but I think that this is where the problem is. Make sure that you are using the correct username and password that you set on your SuperContaine server and that your Apache/IIS server is not requiring a username and password. The username and password that you set in SCSetBaseURL is for the SuperContainer Server UN/PW, not the IIS/Apache server. The plugin will not be able to communicate with SuperContainer if your web server is blocking traffic by requiring additional authentication information.

If you are having trouble with the scripting for this you may just want to copy the files from your old server to the new server using your network or an external hard drive.

Both solutions work perfectly fine when opened alone after a fresh start of filemaker. The implementations do not produce those auth errors. A second (or third, fourth, fifth) database accessing the same subdomain+domain works fine as well. The problem occurs when you attempt to use two solutions opened in the same filemaker instance each accessing a different subdomain (possibly full domain, but I haven't tested that.)

The username/passwords are correct for the supercontainer, and work fine, the authentication problem results from failing to actually send the correct data (username at least) which is indicated in the supercontainer server logging a null username attempt. The IIS itself has no authorization requirement on the directory.

[Smef]

The problem occurs when you attempt to use two solutions opened in the same filemaker instance each accessing a different subdomain (possibly full domain, but I haven't tested that.)

This is correct. Your SuperContainer Base URL is set for your instance of filemaker, not per-database. If you change the base URL any plugin function calls in any database that you have open will try to use the new base URL.