Ralf,
Thanks - I was finally able to get back to this issue once again. Full request logs were already turned on, that did not provide any insight into the cause of the 403 error. Turning on the debug in phpgwapi/inc/class.groupdav_handler.inc.php, following additional lines are generated in the Apache error log
[Sun May 05 11:08:31 2013] [error] [client xxx.xxx.xxx.xxx] addressbook_groupdav::__construct() contact_repository=ldap, account_repository=ldap, REQUEST_URI=/egroupware/groupdav.php/addressbook/ --> path_attr=id, path_extension=.vcf
[Sun May 05 11:08:31 2013] [error] [client xxx.xxx.xxx.xxx] addressbook_groupdav::__construct() contact_repository=ldap, account_repository=ldap, REQUEST_URI=/egroupware/groupdav.php/addressbook/C5ADB205-0670-0001-2484-1F6C79B5F740.vcf --> path_attr=id, path_extension=.vcf
[Sun May 05 11:08:31 2013] [error] [client xxx.xxx.xxx.xxx] addressbook_groupdav::put(Array([path] => /addressbook/C5ADB205-0670-0001-2484-1F6C79B5F740.vcf[content_length] => 240[content_type] => text/vcard; charset=utf-8[content] => BEGIN:VCARD\rVERSION:3.0\rPRODID:-//Inverse inc.//SOGo Connector 1.0//EN\rUID:C5ADB205-06B0-0001-628A-1BD31620B700\r [DATA REMOVED] \rEND:VCARD\r\r),C5ADB205-0670-0001-2484-1F6C79B5F740.vcf,15)
[Sun May 05 11:08:31 2013] [error] [client xxx.xxx.xxx.xxx] groupdav_handler::_common_get_put_delete(PUT,C5ADB205-0670-0001-2484-1F6C79B5F740) 403 Forbidden/404 Not Found: read(C5ADB205-0670-0001-2484-1F6C79B5F740)==false
[Sun May 05 11:08:31 2013] [error] [client xxx.xxx.xxx.xxx] addressbook_groupdav::put(,‘C5ADB205-0670-0001-2484-1F6C79B5F740’, 15, ‘’) returning ‘403 Forbidden’
[Sun May 05 11:08:31 2013] [error] [client xxx.xxx.xxx.xxx] addressbook_groupdav::__construct() contact_repository=ldap, account_repository=ldap, REQUEST_URI=/egroupware/groupdav.php/addressbook/ --> path_attr=id, path_extension=.vcf
Is there anything further you can tell about the problem from these?
Regards,
Debasis
Hi,
Experts,
Can anybody provide further ideas on how to debug this issue? In a
nutshell, attempt to add a contact via GroupDAV fails with a “403
Forbidden” message - however, updates and deletes work fine. Calendar
event create, update and delete are working as well. The issue is
client independent; iPhone, Thunderbird-SoGo and KDE-Kontact all produce
the same result. I have also eliminated LDAP vs SQL address book
storage as a factor - the 403 messages appear in both situations.
From the log I see that the update and add are both HTTP PUT commands,
but haven’t been able to find any difference in the request or response
messages that would let one differentiate between the two.
Difference could be HTTP headers send with PUT requests.
First step to diagnose these problems is to enable full request log to
files directory in CalDAV/CardDAV preferences and provide full logs of
the two requests.
If these logs show nothing suspicious, you can enable debug logging in
phpgwapi/inc/class.groupdav_handler.inc.php (at line ~31, set it to
level 1), to see what caused EGroupware to return a 403 Permission denied.
Additionally you can uncomment a log statement in
addressbook/inc/class.addressbook_bo.inc.php right before return of
check_perms method (at line 1082 in Trunk, might be a little different
in 1.8.004).
Anyway we are again in the situation that not all fixes from Trunk or
EPL are backported to 1.8.004, as versions are get more and more apart.
So it might make sense to check with Trunk, if the problems exists there
too.
Ralf
Regards,
Debasis Datta
From: Dr. Deft drdeft@yahoo.com
To: "development of eGroupWare, for active developers"
egroupware-developers@lists.sourceforge.net
Sent: Saturday, April 6, 2013 3:09 PM
Subject: Re: [eGroupWare-developers] Carddav Update Works but Add Fails
With respect to the vcf string, it is generated by the client, e.g. the
Thunderbird connector/ or iOS and is not under the user’s control. To
be sure, I have manually created ldap contacts with that
identical string as UID, and did not have any issues. I was able to
modify and delete that same contact from the clients.
My iOS version is 6.1.3. Having the .htaccess file with iOS rewrite
directives does not make any difference in this case. Also, the issue
is not iOS specific, it happens from the Thunderbird/SoGo connector as
well. I have no issues on the calendar / CalDAV side - can add events
from the client flawlessly.
As a desperate attempt, I have tried copying the vcf file by mounting
the addressbook as a WebDAV share on localhost, but received the same
error. I can however see the existing vcf files and edit them in place
without problems.
Turning off compression does not make any difference either. I can also
create contacts directly in the ldap by binding as an end user, so it is
not a permission (ldap olcAccess configuration) issue.
Not much details is available in the log beyond the HTTP PUT command
generating a “403 forbidden” response.
I am out of ideas as to how else to debug this. Moving contacts out of
LDAP to MySQL is not an option due to other applications leveraging
OpenLDAP via direct bind.
Regards,
Debasis Datta
From: David C. Rankin drankinatty@suddenlinkmail.com
To: egw-devel egroupware-developers@lists.sourceforge.net
Sent: Wednesday, April 3, 2013 4:35 PM
Subject: Re: [eGroupWare-developers] Carddav Update Works but Add Fails
David,
Thanks - this is however confounding, since I have no issues on the
CalDav
side. On the CardDav side, I can modify an existing entry or delete
one without
any problem. The “403 Forbidden” message appears only when I try to
add a
contact from the client - be it Thunderbird or iPhone. Contact
additions via
the web interface work, so ldap addressbook setup and access control
are correct
as well.
Are there GroupDav related Apache vhost or .htaccess configuration
that you are
using - if so can you share those?
Regards,
Debasis Datta
Dr. Deft,
It is a shot in the dark, but I note that your PUT calls for the failing
contact ‘add’ have the .vcf string in all caps while the remaining
successful
transactions are in lower case. I have NO IDEA if this makes any
difference –
this was just an observation.
There was special groupdav setup required in
egroupware/groupdav.htaccess when
IOS 4.3 was released. It has been a long time ago. Check your
groupdav.htaccess
file:
RewriteEngine On
RewriteBase /
RewriteRule ^.well-known/(caldav|carddav)$ /egroupware/groupdav.php/ [R]
RewriteCond %{REQUEST_METHOD} ^(PROPFIND|OPTIONS)$
RewriteRule ^/$ /egroupware/groupdav.php/ [R]
iOS 4.3+ calendar requires that to autodetect accounts
RewriteRule ^(/principals/users/.*)$ /egroupware/groupdav.php$1 [R]
IOS 4.3 caused auto-configuration to stop working, but I believe Ralf
fixed it
long ago.
The only other suggestion I would have is to capture the output of
your server
access and error logs to see if you can further identify what
page/link/call the
contact add is choking on. Also, if you have enabled compression for
webserver
data transfer (apache - mod_deflate.so http://mod_deflate.so/), you
might try disabling compression and
see if that makes any difference. I haven’t had compression without any
problem,
but it might be worth testing.
These are basically guesses. I will need someone more familiar with the
contact add process to chime in. All I can do is confirm that with 1.8
svn, I
have not had the same issue. Of course 403 screams permission issues,
but I’m
not sure how you would go about finding out where the issue is. If
update and
delete work, that seems to imply permissions are OK unless a new 'add’
is cached
somewhere before being added to the mysql table – that I don’t know…
–
David C. Rankin, J.D.,P.E.
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
mailto:eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
mailto:eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
–
Ralf Becker
Director Software Development
Stylite AG
Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30
Email: rb@stylite.de
www.stylite.de | www.egroupware.org
Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer
VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany
