Hi Marijn,
I was getting ready to send you the files you requested, and also set up a test account for you on my server. Then I thought to test the behavior again, and the problem was gone.
It turns out that if I access the calendar feature now on an account that has not previously used it (or perhaps simply not yet accessed the SurgeWeb calendar pane), it works as expected.
So something I changed along the way must have improved the situation, perhaps one of your suggestions.
What remains is that on my main account, I'm stuck at the error
Cal Request Failed: Error downloading
/usr/local/surgemail/surgeweb/work/ferebee.net/c/f/cf/tmp_xxx_xxxxxxxxx_16594757 0/4096 (1)
which continues to appear if I try to do anything with the calendar pane in SurgeWeb. (The last number after tmp_ is persistent across logout/login, but has changed since I restarted SurgeMail.)
At the moment, I'd be satisfied if I could just un-stick this one account. How can I delete it from the SurgeWeb calendaring database? The SabreDav side of things seems to be OK, as sync between my Macs and iOS devices works, but I don't mind losing the calendar data as I can just re-import it through OS X Calendar.
That being said, I'll be glad to send you any data from the server that will help you debug the situation I'm seeing if you want to pursue it.
Best,
Chris
Am 24.04.2013 um 22:28 schrieb Surgemail Support (Marijn) <surgemailHIDDEN@t@netwinsite.com>:
> Bother... I guess I was being too hopeful the fix was that :-)
>
> So access to the ssl pages does not go through Apache right? So it sounds like that should not be part of the problem.
>
> Could you drop me (OFFLIST) your surgemail.ini, surgeweb config_global.dat, and your apache configuration file just in case) and the url you are connecting to surgeweb on and I'll do some further experimentation to see if I can reproduce what you are seeing.
>
> Marijn
>
>
> On Tuesday 23/04/2013 at 9:45 pm, Chris Ferebee wrote:
>> Hi Marijn,
>>
>> https_required is enabled. Specifically, in /usr/local/surgemail/surgeweb/custom/config_global.dat I have
>>
>> https_required true
>>
>> as set through the SurgeWeb Customisation page ("Editing global customisation").
>>
>> g_ssl_require_web is also set via the Security web page. I have restarted SurgeMail after
>>
>> Perhaps I should mention that I have Apache running on port 80 on the SurgeMail server. Its only purpose is to redirect most URLs to the webmail login page on port 443 and another URL to the management web interface on port 7025. SurgeMail is listening on port 443 for webmail as well as other ports such as 7995.
>>
>> What else can I check?
>>
>> Thanks,
>> Chris
>>
>>
>> Am 23.04.2013 um 10:47 schrieb Surgemail Support (Marijn) <surgemailHIDDEN@t@netwinsite.com>:
>>
>>> I just ran some tests, and yes there is definitely some slightly odd interaction going on between the various ways of enforcing ssl and surgeweb calendaring. You actually do not need to put any port numbers in g_url_alias, but doing so does change the behaviour / reported errors as you have found.
>>>
>>> There is a surgeweb level setting to enforce ssl on surgeweb web requests:
>>> https_required true
>>> If this is set surgeweb will detect the need for ssl and connect to caldav / user.cgi etc using ssl. This can be set on surgeweb customisation page or any of the surgeweb config_*.dat files.
>>>
>>> As it stands if this is not set and just g_ssl_require_web is used then surgeweb tries to connect to caldav on the non ssl port and it fails with a variety of ssl related and seemingly unrelated error messages.
>>>
>>> If you use just https_required and do not use g_ssl_require_web at the surgeweb level any incoming requests on the http port will be automatically redirected to the https port. This configuration would mean that you do not have strict ssl enforcement on the other surgemail web interfaces.
>>>
>>> Anyway, let me know if the addition of "https_required true" does the trick in solving your calendaring issues.
>>>
>>> Marijn
>>>
>>> On Tuesday 23/04/2013 at 8:14 am, surgemailHIDDEN@etwinsite.com wrote:
>>>> I've gotten past the first error message now (550 Secure https: link required for webmail) when trying to access the CalDAV calendars in SurgeWeb.
>>>>
>>>> Previously, the "Ports" field was empty for all the alias entries on the g_url_alias page. I never thought to change that, as SurgeWeb webmail has been working fine AFAICS.
>>>>
>>>> I changed various settings, but it was after I put "443" (my secure SurgeWeb port) in all of the fields that the original error (Secure https: link required) went away.
>>>>
>>>> Now I get a different error when I click on the "Calendar" link in the left column in SurgeWeb, or the "Configure" button in the left Calendar pane:
>>>>
>>>> Cal Request Failed: Error downloading
>>>> /usr/local/surgemail/surgeweb/work/ferebee.net/c/f/cf/tmp_xxx_xxxxxxxxx_20270873 0/4096 (1)
>>>>
>>>> Again, the right pane shows "CalDAV calendars" and an empty list of "Your Calendars" and "Shared Calendars". My primary need at this point is to be able to configure the sharing.
>>>>
>>>> Best,
>>>> Chris Ferebee
>>>>
>>>>
>>>> Am 22.04.2013 um 15:58 schrieb Chris Ferebee HIDDEN@ebee.net>:
>>>>
>>>>> I'm trying to set up CalDAV for Mac and iOS users on SurgeMail 6.3d72.
>>>>>
>>>>> To grant shared access to calendars, I understand that we need to use the Calendars pane in SurgeWeb. However, it doesn't display any calendars. Instead, it shows the error message
>>>>>
>>>>> Cal Request Failed: 550 Secure https: link required for webmail - change http to https in url
>>>>>
>>>>> This is undoubtedly caused by the fact that I have set up my server to redirect all HTTP requests to the webserver domain to the HTTPS login page.
>>>>>
>>>>> Calendar sync for a single user between OS X 10.8.3 and iOS 6.1.3 seems to work fine with automatic setup. Access to webmail also works as expected.
>>>>>
>>>>> Where can I change the URL for calendar access from SurgeWeb, as suggested in the error message?
|
