[Tickets #11638] Re: ActiveSync :: The Autodiscover URL must be configurable, not extracted from the email address performing the query.

[bugs at horde.org]

BITTE NICHT AUF DIESE NACHRICHT ANTWORTEN. NACHRICHTEN AN DIESE  
E-MAIL-ADRESSE WERDEN NICHT GELESEN.

Ticket-URL: http://bugs.horde.org/ticket/11638
------------------------------------------------------------------------------
  Ticket           | 11638
  Aktualisiert Von | torben at dannhauer.info
  Zusammenfassung  | ActiveSync :: The Autodiscover URL must be configurable,
                   | not extracted from the email address performing the
                   | query.
  Warteschlange    | Horde Framework Packages
  Version          | Git master
  Typ              | Enhancement
  Status           | Feedback
  Priorität        | 1. Low
  Milestone        |
  Patch            |
  Zuständige       | Michael Rubinsky
------------------------------------------------------------------------------


torben at dannhauer.info (2012-11-05 20:02) hat geschrieben:

>>> If you have a single horde installation serving a couple of domains,
>>> you oftne have only one SSL certificate covering the domain of your
>>> horde installation, not of all virtual domains the horde installation
>>> serves.
>>>
>>> Because the AutoDiscover feature is usually performed via SSL and
>>> mosts clients quit autodiscovery if the find a untrusted or invalid
>>> SSL certificate, it is mandatory to return an ActiveSync URL covered
>>> with that SSL certificate, not with URL derived from the email Domain.
>>
>> The host is NOT directly calculated on ther server from the email
>> address provided by the user/client. It's parsed out of the result of
>> Horde::url(), which returns a URL based on $conf['server']['name'].
>>
>> Are you using virtual-domain specific configuration files?  If so,
>> that might explain why this is happening since the *client* uses the
>> email address to determine which server to query for the
>> Autodiscovery.
>>
>> Telling ActiveSync to use the one domain for all activesync requests
>> will cause your custom domain specific configuration files to be
>> ignored.
>>
>> Instead of adding this as a configuration option, I'm going to add a
>> new hook. I've had various hooks planned for autodiscover but were
>> pretty low priority for me.
>
> Hmm, that sounds horde has already the right behaviour I need. Maybe  
> I've mixed something up, I was hunting several horde problems in the  
> last days.
>
> I'll check this again after work and will comment this bug again.
>
> Yeah hooks sounds great, this would allow to modify the autodiscover  
> behavior without adding lots of new options to the configuration.
>
> Torben

Hi,
I have no vhost configs, I have a single horde installation for  
multiple domains..

Of course the client uses the email address to determine the url to  
query for autodetection, but each of my virtual domains has a DNS  
redirect entry and horde is only availableto redirect autodiscover  
queries to www.my-host.tld - and it works with outlook. So according  
to the specs, each client device should restart the autodiscover at  
www.my-host.tld.

I have verified the problem:
My horde is located at 'www.my-host.tld' while to have only a single  
SSL certificate to buy.
emailadresses with user at virtual-domain.tld get a ActiveSync URL  
'https://virtual-domain.tld/Microsoft-Server-ActiveSync' but not  
'https://www.my-host.tld/Microsoft-Server-ActiveSync'
Even when I use an email-address user at my-host.tld it uses  
'https://my-host.tld/Microsoft-Server-ActiveSync' and not  
'https://www.my-host.tld/Microsoft-Server-ActiveSync'
-- is that the correct behaviour?

Anyway, the tip to specify my correct horde URL in  
$conf['server']['name'] as $conf['server']['name'] = 'www.my-host.tld'  
instead of using SERVER_NAME did the trick, now it works correctly.
For me this issue is closed...

Many thanks,
Torben

By the way: the interesting question is why my webserver delivers  
horde querys vor http://virtual.tld but the apaceh vhost is configured  
only for https://www.my-host.tld .... THAT seems to  be a true bug ;)