Mailing List Archive

On Fri, 2010-05-28 at 09:59 +0200, Marc Patermann wrote:
> >>
> >> I found this in the documentation:
> >> $c->default_relationships = array();
> >
> > That setting only applies pre-0.9.8. From 0.9.8 onwards it is not
> > needed, because it is possible to set the default permissions granted to
> > 'everyone' more straightforwardly.

> How ist that?

Each principal, and each calendar of each principal, has a 'default
privileges' field where you can set the privileges granted to 'everyone'
by that principal (or calendar).

If you don't set the 'default privileges' on a calendar, then the
'default privileges' which have been set on the principal owning the
calendar will apply to that calendar instead.


> > The admin user can access any calendar, however, so you could script a
> > backup in that way.
> OK, this is fine.
> Is there an easy way to get a list of all existing calendars on the server?

The admin UI can only list collections per individual, but this is easy
enough in SQL:

psql -U davical_app davical -c 'SELECT dav_name, dav_displayname FROM
collection'

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-users/attachments/20100528/f460f08d/attachment.pgp>
-------------- next part --------------

-------------- next part --------------
_______________________________________________
rscds-general mailing list
rscds-general at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rscds-general

Andrew,

Andrew McMillan schrieb am 02.05.2010 10:25 Uhr:
> On Fri, 2010-04-30 at 14:29 +0200, Marc Patermann wrote:

>> One way to archive this would be a backup via WebDAV on each and every
>> calendar. There needs to be a list of all calendars and a user who has
>> read access to all the data.
> The admin user can access any calendar, however, so you could script a
> backup in that way.
I thought it would be easy to dump the data with curl. So I tried
# curl --anyauth -u admin:passed http://server/davical/caldav.php/user2/home
which just gave me "Please log in for access to this system."
So I tried with a browser first.

I tried the following:

- access the calendar URL of one user with a browser
http://server/davical/caldav.php/user2/home/
- the calendar has me - user2 - with read access granted.
- I try three time to authenticate as admin with no success, I do not
get the data.
- I tried to authenticate as user1, which works - I can download the
data "3eDOv___.ics.part"
- I granted admin with read access to the calendar and tried again -
again no success! "Please log in for access to this system."

The admin user seams not to have any rights on the calendar.
All the users - except admin - are in ldap.

$c->do_not_sync_from_ldap = array( 'admin' => true, 'mrbond' => true );

What is wrong here?


Marc

Hi,

Andrew McMillan schrieb am 28.05.2010 12:25 Uhr:
> On Fri, 2010-05-28 at 09:59 +0200, Marc Patermann wrote:
>>>> I found this in the documentation:
>>>> $c->default_relationships = array();
>>> That setting only applies pre-0.9.8. From 0.9.8 onwards it is not
>>> needed, because it is possible to set the default permissions granted to
>>> 'everyone' more straightforwardly.
>
>> How ist that?
>
> Each principal, and each calendar of each principal, has a 'default
> privileges' field where you can set the privileges granted to 'everyone'
> by that principal (or calendar).
So this is in the UI. The user has to do it himself, right?
I want this to be predefined. Can I still use the
$c->default_relationships option with 0.9.9?

> If you don't set the 'default privileges' on a calendar, then the
> 'default privileges' which have been set on the principal owning the
> calendar will apply to that calendar instead.
>
>
>>> The admin user can access any calendar, however, so you could script a
>>> backup in that way.
>> OK, this is fine.
>> Is there an easy way to get a list of all existing calendars on the server?
>
> The admin UI can only list collections per individual, but this is easy
> enough in SQL:
>
> psql -U davical_app davical -c 'SELECT dav_name, dav_displayname FROM
> collection'
Thanks!


Marc

On 7 Jun 2010, at 16:11, Marc Patermann wrote:

> I thought it would be easy to dump the data with curl. So I tried
> # curl --anyauth -u admin:passed http://server/davical/caldav.php/user2/home
> which just gave me "Please log in for access to this system."

If you want to use the command line to dump a calendar, try this:
wget -O <save_file.ics> --user=<user> --password=<pass> -q http://server/caldav.php/user2/home.ics


Regards,
Keith.

Keith,

Keith Smith schrieb am 11.06.2010 10:58 Uhr:
> On 7 Jun 2010, at 16:11, Marc Patermann wrote:

>> I thought it would be easy to dump the data with curl. So I tried
>> # curl --anyauth -u admin:passed http://server/davical/caldav.php/user2/home
>> which just gave me "Please log in for access to this system."
>
> If you want to use the command line to dump a calendar, try this:
> wget -O <save_file.ics> --user=<user> --password=<pass> -q http://server/caldav.php/user2/home.ics
Thanks for your response!
This is more or less the same, but does not solve my problem.

The main problem is that - as I tried to describe before - the admin
user cannot access the calendar data!

# wget -v -O bal.ics --user=admin --password=xxxx
http://server/davical/caldav.php/user/home.ics
--2010-06-11 11:33:45-- http://server/davical/caldav.php/user/home.ics
Resolving server... 10.49.6.72
Connecting to server|10.49.6.72|:80... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Reusing existing connection to server:80.
HTTP request sent, awaiting response... 401 Unauthorized
Authorization failed.

Whereas I can log in with the same credential in the admin UI just fine.
Even when admin has the right given in the UI (whereas Andrew stated
this might not be necessary) it does not work.


Marc

On Fri, 2010-06-11 at 11:43 +0200, Marc Patermann wrote:
> Keith,
>
> Keith Smith schrieb am 11.06.2010 10:58 Uhr:
> > On 7 Jun 2010, at 16:11, Marc Patermann wrote:
>
> >> I thought it would be easy to dump the data with curl. So I tried
> >> # curl --anyauth -u admin:passed http://server/davical/caldav.php/user2/home
> >> which just gave me "Please log in for access to this system."
> >
> > If you want to use the command line to dump a calendar, try this:
> > wget -O <save_file.ics> --user=<user> --password=<pass> -q http://server/caldav.php/user2/home.ics
> Thanks for your response!
> This is more or less the same, but does not solve my problem.
>
> The main problem is that - as I tried to describe before - the admin
> user cannot access the calendar data!

Yes, that's true.

You can create a user (or just use admin) and add rights to access all
calendars.

One change in 0.9.8 and later is that the access control over a calendar
is decidedly with the owner of the calendar.

Of course if you have access to the SQL database you could insert a row
for each principal granting access to their calendars to the admin user.
and then all of the below would work just fine.

Cheers,
Andrew.

>
> # wget -v -O bal.ics --user=admin --password=xxxx
> http://server/davical/caldav.php/user/home.ics
> --2010-06-11 11:33:45-- http://server/davical/caldav.php/user/home.ics
> Resolving server... 10.49.6.72
> Connecting to server|10.49.6.72|:80... connected.
> HTTP request sent, awaiting response... 401 Unauthorized
> Reusing existing connection to server:80.
> HTTP request sent, awaiting response... 401 Unauthorized
> Authorization failed.
>
> Whereas I can log in with the same credential in the admin UI just fine.
> Even when admin has the right given in the UI (whereas Andrew stated
> this might not be necessary) it does not work.
>
>
> Marc
>

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You have a deep appreciation of the arts and music.
------------------------------------------------------------------------

-------------- 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-users/attachments/20100611/1ad691d2/attachment.pgp>
-------------- next part --------------

hi,

works for me on davical-0.9.7.6-0.
here's my wget-call:

<snip>
cd /path/to/backupdir

for user in $users; do
wget -q -O ${user}.ics --no-check-certificate --http-user=admin \
--http-password=sUpErSeCuRe \
https://caldav.srv.tld/caldav.php/${user}/home 2>/dev/null
done
<snap>

expect the '.ics' in the server-url its the same call as andrew has
mentioned.

i call: https://caldav.srv.tld/caldav.php/${user}/home
without the '.ics'

user 'admin' is NOT on explicitly authorized to read the other calendars.


cheers,
chris


--On Freitag, Juni 11, 2010 11:43:24 +0200 Marc Patermann
<hans.moser at ofd-z.niedersachsen.de> wrote:

> Keith,
>
> Keith Smith schrieb am 11.06.2010 10:58 Uhr:
>> On 7 Jun 2010, at 16:11, Marc Patermann wrote:
>
>>> I thought it would be easy to dump the data with curl. So I tried
>>> # curl --anyauth -u admin:passed
>>> # http://server/davical/caldav.php/user2/home
>>> which just gave me "Please log in for access to this system."
>>
>> If you want to use the command line to dump a calendar, try this:
>> wget -O <save_file.ics> --user=<user> --password=<pass> -q
>> http://server/caldav.php/user2/home.ics
> Thanks for your response!
> This is more or less the same, but does not solve my problem.
>
> The main problem is that - as I tried to describe before - the admin
> user cannot access the calendar data!
>
># wget -v -O bal.ics --user=admin --password=xxxx
> http://server/davical/caldav.php/user/home.ics
> --2010-06-11 11:33:45-- http://server/davical/caldav.php/user/home.ics
> Resolving server... 10.49.6.72
> Connecting to server|10.49.6.72|:80... connected.
> HTTP request sent, awaiting response... 401 Unauthorized
> Reusing existing connection to server:80.
> HTTP request sent, awaiting response... 401 Unauthorized
> Authorization failed.
>
> Whereas I can log in with the same credential in the admin UI just fine.
> Even when admin has the right given in the UI (whereas Andrew stated
> this might not be necessary) it does not work.
>
>
> Marc
>
> -------------------------------------------------------------------------
> ----- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> rscds-general mailing list
> rscds-general at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rscds-general



mit freundlichen gruessen
christoph steidl

--
netcar24 GmbH

Systems Engineer

Technologiezentrum Koblenz
Universit?tsstrasse 3
56070 Koblenz

Gesch?ftsf?hrer / CEO: Michael Deuse
Gesch?ftsf?hrer / CTO: Karsten Stoppe
Amtsgericht Koblenz HRB 20055

HOTLINE: +49-1805-808444 *)
FAX: +49-261-8854350

cs at netcar24.com
www.netcar24.com
www.re-fleet.com

Autohausverwaltung f?r Profis
Softwaresolutions for automotive retail

*) 14Cent/min aus dem deutschen Festnetz
max. 42Cent/min aus dem Mobilfunknetz

-------------------------------------------------------------------

Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort
netcar24 und vernichten Sie diese Mail. Das unerlaubte Kopieren
sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

Disclaimer: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity
to whom they are addressed. If you are not the intended recipient,
please notify netcar24 immediately and delete this email from your
system. Please note that any views or opinions presented in this email
are solely those of the author and do not necessarily represent those of
the company. Finally, the recipient should check this email and any
attachments for the presence of viruses.
Although this message was scanned for viruses before being sent, the
company accepts no liability for any loss, damage or expense resulting
directly or indirectly from the access of this e-mail or any attached
files.

--------------------------------------------------------------------

Andrew,

Andrew McMillan schrieb am 11.06.2010 13:21 Uhr:
> On Fri, 2010-06-11 at 11:43 +0200, Marc Patermann wrote:
>> The main problem is that - as I tried to describe before - the admin
>> user cannot access the calendar data!
>
> Yes, that's true.
Your wrote 02.05.2010 10:25 Uhr::
> The admin user can access any calendar, however, so you could script a
> backup in that way.

Now I'm a bit confused. Can or can't admin access the data?

> You can create a user (or just use admin) and add rights to access all
> calendars.
I won't and can't do this "by hand" for each and every new user.
For me this needs to by automatically. "Every (new) user has to have
"the ability to get backuped" otherwise the calendar won't get backuped. :(

On the other hand: I tried this and it does not work!
Even if admin has read right on the calendar and/or the principal above,
I do not get access to the data. :(



Marc

On Fri, 2010-06-11 at 14:00 +0200, Christoph Steidl wrote:
> hi,
>
> works for me on davical-0.9.7.6-0.

Yes, although the permissions model changed at version 0.9.8 onwards,
from which point the admin user only got full rights within the admin
UI.

The admin user will again have full rights to read everything in 0.9.9.1
though - this change was subsequent to the release of 0.9.9. The code
below does work for me on my current testing setup.

Cheers,
Andrew.


> here's my wget-call:
>
> <snip>
> cd /path/to/backupdir
>
> for user in $users; do
> wget -q -O ${user}.ics --no-check-certificate --http-user=admin \
> --http-password=sUpErSeCuRe \
> https://caldav.srv.tld/caldav.php/${user}/home 2>/dev/null
> done
> <snap>
>
> expect the '.ics' in the server-url its the same call as andrew has
> mentioned.
>
> i call: https://caldav.srv.tld/caldav.php/${user}/home
> without the '.ics'
>
> user 'admin' is NOT on explicitly authorized to read the other calendars.
>
>
> cheers,
> chris
>
>
> --On Freitag, Juni 11, 2010 11:43:24 +0200 Marc Patermann
> <hans.moser at ofd-z.niedersachsen.de> wrote:
>
> > Keith,
> >
> > Keith Smith schrieb am 11.06.2010 10:58 Uhr:
> >> On 7 Jun 2010, at 16:11, Marc Patermann wrote:
> >
> >>> I thought it would be easy to dump the data with curl. So I tried
> >>> # curl --anyauth -u admin:passed
> >>> # http://server/davical/caldav.php/user2/home
> >>> which just gave me "Please log in for access to this system."
> >>
> >> If you want to use the command line to dump a calendar, try this:
> >> wget -O <save_file.ics> --user=<user> --password=<pass> -q
> >> http://server/caldav.php/user2/home.ics
> > Thanks for your response!
> > This is more or less the same, but does not solve my problem.
> >
> > The main problem is that - as I tried to describe before - the admin
> > user cannot access the calendar data!
> >
> ># wget -v -O bal.ics --user=admin --password=xxxx
> > http://server/davical/caldav.php/user/home.ics
> > --2010-06-11 11:33:45-- http://server/davical/caldav.php/user/home.ics
> > Resolving server... 10.49.6.72
> > Connecting to server|10.49.6.72|:80... connected.
> > HTTP request sent, awaiting response... 401 Unauthorized
> > Reusing existing connection to server:80.
> > HTTP request sent, awaiting response... 401 Unauthorized
> > Authorization failed.
> >
> > Whereas I can log in with the same credential in the admin UI just fine.
> > Even when admin has the right given in the UI (whereas Andrew stated
> > this might not be necessary) it does not work.
> >
> >
> > Marc
> >
> > -------------------------------------------------------------------------
> > ----- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit. See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > rscds-general mailing list
> > rscds-general at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/rscds-general
>
>
>
> mit freundlichen gruessen
> christoph steidl
>
> --
> netcar24 GmbH
>
> Systems Engineer
>
> Technologiezentrum Koblenz
> Universit?tsstrasse 3
> 56070 Koblenz
>
> Gesch?ftsf?hrer / CEO: Michael Deuse
> Gesch?ftsf?hrer / CTO: Karsten Stoppe
> Amtsgericht Koblenz HRB 20055
>
> HOTLINE: +49-1805-808444 *)
> FAX: +49-261-8854350
>
> cs at netcar24.com
> www.netcar24.com
> www.re-fleet.com
>
> Autohausverwaltung f?r Profis
> Softwaresolutions for automotive retail
>
> *) 14Cent/min aus dem deutschen Festnetz
> max. 42Cent/min aus dem Mobilfunknetz
>
> -------------------------------------------------------------------
>
> Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
> E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort
> netcar24 und vernichten Sie diese Mail. Das unerlaubte Kopieren
> sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
>
> Disclaimer: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity
> to whom they are addressed. If you are not the intended recipient,
> please notify netcar24 immediately and delete this email from your
> system. Please note that any views or opinions presented in this email
> are solely those of the author and do not necessarily represent those of
> the company. Finally, the recipient should check this email and any
> attachments for the presence of viruses.
> Although this message was scanned for viruses before being sent, the
> company accepts no liability for any loss, damage or expense resulting
> directly or indirectly from the access of this e-mail or any attached
> files.
>
> --------------------------------------------------------------------
>
>

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
I have not seen high-discipline processes succeed in commercial
settings. - Alistair Cockburn

------------------------------------------------------------------------

-------------- 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-users/attachments/20100612/03706ad2/attachment.pgp>
-------------- next part --------------

Hi,

Andrew McMillan schrieb am 11.06.2010 14:33 Uhr:
> On Fri, 2010-06-11 at 14:26 +0200, Marc Patermann wrote:
>> Andrew McMillan schrieb am 11.06.2010 13:21 Uhr:
>>> On Fri, 2010-06-11 at 11:43 +0200, Marc Patermann wrote:
>>>> The main problem is that - as I tried to describe before - the admin
>>>> user cannot access the calendar data!
>>> Yes, that's true.
>> Your wrote 02.05.2010 10:25 Uhr::
>>> The admin user can access any calendar, however, so you could script a
>>> backup in that way.
>> Now I'm a bit confused. Can or can't admin access the data?
>
> I'm pretty sure that since 0.9.8 the 'admin' user cannot access anything
> via dav which has not been granted.
>
> It wouldn't be too hard to add a configuration setting that allowed
> adminn to have all access to everything, though.
OK, after the clarification in thread "DB users have no access to data
when ldap configured?" the solution was really simple: Make an LDAP user
administrator.
Now the LDAP user has access to all calendar data - as it seams to me
right now - and the user can download all the calendar data for backup.
I'm going to check this out a little bit more later this day, I hope.


Marc

> OK, after the clarification in thread "DB users have no access to data
> when ldap configured?" the solution was really simple: Make an LDAP user
> administrator.
>

just a short note:

$c->authenticate_hook['optional']=true;

should also allow the admin to access the Data, as this option makes the
ldap authentication optional.

jonas