Hello!
For the case that a client contacts the server via Bluetooth (and thus
must have paired successfully) I'd like to accept the connection request
regardless which credentials the client provides.
I'm running with the following configuration:
<server type='plugin'>
<plugin_module>SyncEvolution</plugin_module>
<plugin_sessionauth>yes</plugin_sessionauth>
<plugin_deviceadmin>yes</plugin_deviceadmin>
<requestedauth>none</requestedauth>
<requiredauth>none</requiredauth>
<autononce>yes</autononce>
This redirects session and device handling calls into SyncEvolution
code. It always returns Password_ClrText_OUT as password mode. I see
that our Session_Login() is called from here:
#0 sysync::TCustomImplAgent::SessionLogin (this=0x2b3d110, aUserName=0x2aca500
"test",
aAuthString=0x2aca670 "rKOc35gVO51AvKnMKMIskw==",
aAuthStringType=sysync::sectyp_md5_V11,
aDeviceID=0x2acaa18 "sc-pim-117cdd45-3892-4a2d-ae62-4c98cb0f3eae")
at /home/pohly/syncevolution/libsynthesis/src/sysync/customimplagent.cpp:815
#1 0x0000000000683f81 in sysync::TSyncSession::checkCredentials
(this=0x2b3d110,
aUserName=0x2aca500 "test", aCred=0x2aca670 "rKOc35gVO51AvKnMKMIskw==",
aAuthType=sysync::auth_md5)
at /home/pohly/syncevolution/libsynthesis/src/sysync/syncsession.cpp:4048
#2 0x0000000000685657 in sysync::TSyncSession::checkCredentials
(this=0x2b3d110,
aUserName=0x2aca500 "test", aCredP=0x2aca520, astatuscomma...@0x2aca840)
at /home/pohly/syncevolution/libsynthesis/src/sysync/syncsession.cpp:3981
#3 0x0000000000771726 in sysync::TSyncAgent::ServerMessageStarted
(this=0x2b3d110,
aContentP=0x2aca2d0, astatuscomma...@0x2aca840, aBad=false)
at /home/pohly/syncevolution/libsynthesis/src/sysync/syncagent.cpp:1814
#4 0x000000000076d7b4 in sysync::TSyncAgent::MessageStarted (this=0x2b3d110,
aContentP=0x2aca2d0,
astatuscomma...@0x2aca840, aBad=false)
In other words, despite
<requestedauth>none</requestedauth>
<requiredauth>none</requiredauth>
credentials are checked and have to match.
Should these settings have an effect when using the DB to authenticate
users? It doesn't seem that they do, but I also don't see any other way
to disable the login check.
Hmm, perhaps I misunderstood the meaning of these settings. In
TSyncAgent::isAuthTypeAllowed() I see that fRequiredAuth is checked only
to see whether the client's credentials are "strong" enough. If the
client provides credentials, they still have to be correct.
In TSyncSession::checkCredentials(), the relevant code is this:
// first check credentials
// NOTE: This must be done first, to force calling SessionLogin
// in all cases
authok=checkCredentials(aUserName,authdata,authtype);
// now check result
if (!isAuthTypeAllowed(authtype)) {
aStatusCommand.setStatusCode(401); // we need another auth type, tell
client which one
authok=false; // anyway, reject
PDEBUGPRINTFX(DBG_ERROR,("Authorization failed (wrong type of creds),
sending 401 + chal"));
}
else if (!authok) {
// auth type allowed, but auth itself not ok
aStatusCommand.setStatusCode(401); // unauthorized, bad credentials
PDEBUGPRINTFX(DBG_ERROR,("Authorization failed (invalid credentials)
sending 401 + chal"));
}
if (!authok) {
// - add challenge
aStatusCommand.setChallenge(newSessionChallenge());
}
Would it be okay to add something like this before "else if (!authok)"?
It solves the problem for me.
if (!authok && isAuthTypeAllowed(auth_none)) {
authok = true;
}
That changes the meaning of <requiredauth>none</requiredauth> from "all
kinds of authentication methods allowed, including none" to "all kinds
of credentials allowed, including invalid ones". Because a client with
invalid credentials was already allowed to connect by not sending them,
this doesn't make a server setup less secure. It has the advantage that
the client setup becomes easier.
I added my patch to the "master" branch on moblin.org, because it is
needed for SyncEvolution. Please merge if you agree with this change.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
