This dialog allows the software to accept login information from the operating system or web server. Without this feature your end users may have to login twice; once to the operating system and once to the calendar. Settings on this screen apply to all calendars.

Enabling this feature

By default this feature is not enabled and it will not work unless the web server sends an environment variable called $REMOTE_USER. It is not enough to simply change the settings on this form to enable this feature. You must also modify your web server so that $REMOTE_USER is first acquired and then sent with HTTP request. This procedure varies depending on the operating system and web server. Below we present some considerations under each scenario.

In house under Microsoft IIS

In house under Linux web servers

Hosted under Great Hill's calendar hosting service

Under third party hosting

How are permissions calculated

The following algorithm is used to grant permissions to a particular user on any particular calendar:

    if (remote login is enabled and $REMOTE_USER is not empty)
    {
        if ($REMOTE_USER is found in user database)
            proceed to section 1
        else
            grant remote login permission

    } else if (user has not logged in using the calendar login screen)
    {
        grant the calendar default permission
    
    } else
    {
        // section 1
        // Either $remote_user was found or the feature is not enabled
        if (user has specific permission for current calendar)
            grant the specific permission
        else
            grant the user's default permission
    }

Stated less succinctly and more confusingly; if the feature is enable and $REMOTE_USER is not empty grant the user remote login permission unless that user is found in the internal user database in which case grant the user the internal permission. If $REMOTE_USER is empty grant the user the internal user database permission if he/she previously logged or the default calendar permission if not (yes! we know!).

See also: user permissions

An example

A regular user 'joe' logs using your company's normal login procedure when he first accesses your company's intranet. One of the links from the main page of the intranet is to this calendar. 'joe' clicks on the calendar link which sends $REMOTE_USER 'joe'. The calendar software does not find 'joe' in its internal user database. 'joe' gets edit permission - the remote login permission setting.

Further, from home, 'joe' accesses the calendar software directly without having first gone to the intranet home page. 'joe' is granted the calendar's default permission (probably view).

Further, two days later the super user adds 'joe' as an admin user in the calendar's internal user database. The next time 'joe' accesses the calendar from the intranet link after having logged in to the website he/she gets granted admin permission. If he accesses the calendar directly (without the intranet) he would have to login directly to get his admin permission.

There are other ways to accomplish these tasks (if for example your server does not send $REMOTE_USER) but they are not documented. Please call technical support for more information