Sessions and sign-in
Posit Connect administrators can use this page to understand browser sessions, configure session limits, and manage reauthentication for sensitive actions and sign-in. To configure web sudo mode, identify the section for your authentication provider in the configuration file.
How sessions work
Connect stores sessions on the server. Connect generates a cryptographically secure identifier for each session and stores it in the rsconnect and rsconnect-legacy cookies. By default, the cookies are HttpOnly, which prevents JavaScript from accessing them. Connect uses the Secure attribute if you configure it to require HTTPS. When users sign in to Connect, a browser cookie keeps them logged in. For default session lifetime and details about changing it, see Limit session lifetime. The server periodically checks the data store for expired cookies and removes them. By default, the server does this once per hour. Configure the interval with Authentication.CookieSweepDuration. Cookie sweeping does not affect web session lifetime, which you can configure with Authentication.Lifetime. Connect uses session cookies to track and enforce both the session lifetime and inactivity threshold.
Limit session lifetime
By default, Connect enforces the following limits on authenticated sessions:
- Connect invalidates sessions after 24 hours, regardless of activity.
- Connect considers inactive sessions idle and invalidates them after 8 hours.
After Connect invalidates a session, the user must sign in again before continuing to interact with Connect.
These limits follow good security practices by ensuring that users enter their credentials daily.
Administrators can configure the session lifetime and inactivity threshold. Change the maximum session lifetime with Authentication.Lifetime. Set session inactivity with Authentication.Inactivity. Configure these session settings according to your organization’s security policies.
The 24-hour default for Authentication.Lifetime means that Connect revalidates access against your authentication provider (e.g., your Active Directory server) at least once a day. The 8-hour default for Authentication.Inactivity aims to avoid asking a user to sign in again more than once during a typical work day.
The first configuration example uses shorter thresholds than the configured defaults. Users must sign in again after being idle for 30 minutes or after their session lasts for 12 hours. The 30-minute inactivity limit means sessions can remain idle “no longer than a lunch break.”
/etc/rstudio-connect/rstudio-connect.gcfg
[Authentication]
Lifetime = 12h
Inactivity = 30mThe second configuration example uses longer thresholds than the configured defaults. Users must sign in again once a week or after being inactive for a full day. Use this configuration with care. Your organization might want users to sign in again more frequently.
/etc/rstudio-connect/rstudio-connect.gcfg
[Authentication]
Lifetime = 7d
Inactivity = 1dIf a user’s session expires or is considered inactive with an application left running in their browser that application’s process is not terminated immediately. Further attempts to interact with the application then cause it to close and then the user will be asked to reenter credentials.
Applications can outlive sessions when opened in Standalone mode if their timeout settings are greater than Authentication.Inactivity or Authentication.Lifetime. The settings Scheduler.ConnectionTimeout and Scheduler.ReadTimeout determine the default values for how long a browser running an application can remain idle. By default these are set to 1 hour but individual applications may set higher values independently from the server’s settings.
Require reauthentication for sensitive actions
When users perform a sensitive operation in a web browser, such as creating a new API key, Connect asks them to reenter their login credentials. After users enter the correct password, Connect places their session in a privileged state known internally as web sudo mode. Web sudo mode lets users perform these sensitive operations for a certain window of time without entering their password again. This privileged mode exists only within Connect and has no relation to the server’s actual sudo or Pluggable Authentication Modules (PAM) settings.
This feature is not available on servers configured to use Single Sign-On (SSO) via OAuth2, OpenID, SAML, or proxied authentication.
For all other authentication providers, the WebSudoMode and WebSudoModeDuration configuration options are available in the section for that provider. If WebSudoMode is set to false, Connect disables this protection. All authenticated users are then always in privileged mode. WebSudoModeDuration controls how long a user stays in this privileged mode. Configure these options in the section for your authentication provider, such as [Password], [PAM], or [LDAP]:
/etc/rstudio-connect/rstudio-connect.gcfg
; This example is using password authentication. Use PAM or LDAP as appropriate.
[Password]
WebSudoMode = true
WebSudoModeDuration = 10mIn this case, Connect prompts users for their password before they perform sensitive actions. Users can then perform sensitive actions for up to 10 minutes without another prompt. After that point, users must enter their password again before any sensitive action.
Regardless of the setting, web sudo mode does not affect calls made outside a browser using a token or an API key.
Protect sign-in from brute-force and dictionary attacks
With the PAM, LDAP, and Password authentication providers, users sign in by entering their user name and password on the Connect sign-in page. Connect does not rate-limit these sign-in attempts, so you can add a Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) challenge to protect the page from automated attacks.
Set Authentication.ChallengeResponseEnabled to true to enable a CAPTCHA form on the login screen and require users to solve it to authenticate. Both visual and audio CAPTCHA challenges are provided for accessibility needs.