Mailing List Archive

On Thu, 2010-05-20 at 13:17 +0200, Matthias Althaus wrote:
> Hey there,
>
> I'm currently evaluating the usage of DAViCal for a school server
> system. We've got a fully working intra/internet system with an
> existing user database.
>
> I've got the authentication based on the data so far to work that I
> can auth through the web page and also by caldav using Sunbird. I'm
> using the UpdateUserFromExternal() function and all seems fine. The
> problem now is that a user doesn't get his own calendar. I played
> around with all the debugging options and the xml response is "need
> privileges: read".
>
> I tried with another user created through the web interface and the
> problem doesn't exist. Granting this "locale" user a read privilege on
> the (imported) calendar of an "external" one is also working.
>
> Is there anything I've overseen? UpdateUserFromExternal looks fine in
> my eyes and seems to do all the needed stuff. I couldn't find a
> usefull clue in the log yet.

Hi Matthias,

There is one recent commit that fixed an error someone else was seeing,
so perhaps it applies to you also:

http://repo.or.cz/w/awl.git/commit/2d1ec56fcced9fb76ba2a516486d1d13c26f8e72



Also, if you want to debug it I recommend enabling:

$c->dbg['querystring'] = 1;

in your configuration, so you can see the database queries in your
Apache error log. If one of these seems like it should return 1 row but
it is returning 0 rows, then that would be a big clue as to what might
be going wrong.

If you see a 'QF:' in your apache error log that is a query which is
failing, and almost certainly a bug.

Side-by-side comparison of the usr, principal and collection rows for
the working & non-working users would help, too.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Necessity is the mother of documentation
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20100521/5580f49d/attachment.pgp>

Hey Andrew,

thanks for your quick reply. I did already some further debugging and tried to track the problem down. I've dug something out:

For the external user connecting to his own calendar, he's first looking for the called collection "/external.user/home/" and then stepping deeper and checking "/external.user". For the latter he isn't finding a privilege and therefore sending the "need priv" back to the client.

For the local user connecting to the same calendar he's only looking for "/external.user/home" and then done after he found the privelege.

I've attached the relevant part of the log... if that's not working you can find it here: http://pastebin.com/NPMsttkx

Now I wonder a) why he's checking the parent and b) why doesn't the user have rights to read his own principal? Is that something I have to set manually? I tried to give the user principal privileges through the admin interface, but that didn't make a difference.

btw: I'm using the current release from Debian.

Cheers
Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.log
Type: text/x-log
Size: 3485 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20100521/5c6d56be/attachment.bin>

Hi again,

I finally managed to get this sorted out and the error was basicall plain stupid. The $usr I created in my auth function was just missing some additional data like the principal ID and the default rights. This wasn't really mentioned in the doc and I only found it out by digging into the code and compare local and external users side by side.

I now added a simple $usr = getUserByName($username) at the end of my function to load all the relevant data from the database... in the format Davical needs.

Perhaps you should state what data is exactly needed in the $usr object. :)

Best regards
Matthias