> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/stormkit-io/stormkit-io/llms.txt
> Use this file to discover all available pages before exploring further.

# Auth Wall

> Learn how to configure and use the Auth Wall feature to restrict access to your deployments, manage authorized users, and enhance security for sensitive environments.

## Overview

The **Auth Wall** feature allows you to restrict access to your deployments by requiring user authentication. This is particularly useful for protecting sensitive environments, such as staging or preview deployments, ensuring that only authorized users can access them.

You can locate the Auth Wall settings by navigating to **Environment** > **Config** > **Auth Wall**.

## Configuration Modes

The Auth Wall has three main configuration modes:

<CardGroup cols={3}>
  <Card title="Disabled" icon="lock-open">
    No authentication requirement for any deployments. All content is publicly accessible.
  </Card>

  <Card title="All Endpoints" icon="lock">
    Every page and endpoint across all domains requires authentication. Maximum security.
  </Card>

  <Card title="Preview Only" icon="eye-slash">
    Only preview deployments require authentication. Production deployments remain publicly accessible.
  </Card>
</CardGroup>

## Setting Up Auth Wall

<Steps>
  <Step title="Navigate to Auth Wall config">
    Go to **Environment** > **Config** and select the **Auth Wall** tab in the left-hand sidebar
  </Step>

  <Step title="Choose protection mode">
    Select one of the three configuration modes based on your security needs
  </Step>

  <Step title="Add authorized users">
    Add users who should have access to the protected deployments (see Managing Authorized Users below)
  </Step>

  <Step title="Save configuration">
    Click **Save** to apply the Auth Wall settings
  </Step>
</Steps>

## Managing Authorized Users

The **Auth Users** section allows you to manage the list of users who have access to the deployment when the Auth Wall is enabled.

### Viewing Authorized Users

A table displays the list of users with access. Each row includes:

* **Email**: The email address of the authorized user
* **Last Login**: The timestamp of the user's last login (if available)
* **Checkbox**: A checkbox to select the user for removal

### Adding Users

<Steps>
  <Step title="Click Add User">
    Click the **Add User** button (indicated by a `+` icon)
  </Step>

  <Step title="Enter credentials">
    You will be prompted to enter:

    * User's email address
    * Password for the user
  </Step>

  <Step title="Confirm">
    Click create to add the user. They can now access protected deployments.
  </Step>
</Steps>

### Removing Users

To remove a user:

1. Select the user by checking the box next to their email
2. Click the **Remove Selected** button to revoke their access

<Warning>
  Removing a user will immediately revoke their access to the deployment. However, users with active sessions won't be invalidated until their session expires.
</Warning>

## Session Management

By default, a user remains logged in for a maximum of 24 hours. After this period, they will need to re-authenticate.

<Info>
  Sessions are managed server-side for security. Closing the browser does not immediately invalidate the session.
</Info>

## Use Cases

<CardGroup cols={2}>
  <Card title="Staging Protection" icon="shield">
    Protect staging environments from public access while sharing with your team and stakeholders.
  </Card>

  <Card title="Preview Deployments" icon="eye">
    Secure preview deployments for feature branches, allowing only team members to review changes.
  </Card>

  <Card title="Client Reviews" icon="handshake">
    Create secure environments for client reviews before going live, with controlled access.
  </Card>

  <Card title="Internal Tools" icon="tools">
    Protect internal tools and dashboards from unauthorized access.
  </Card>
</CardGroup>

## Best Practices

* **Limit access** - Only add users who need access to the deployment to minimize security risks
* **Regularly review users** - Periodically review the list of authorized users and remove those who no longer need access
* **Use for sensitive environments** - Enable the Auth Wall for environments that contain sensitive data or are not ready for public access
* **Strong passwords** - Use strong, unique passwords for each authorized user
* **Combine with other security measures** - The Auth Wall is a layer of protection but should not be used as the primary layer to secure your application

## Troubleshooting

<AccordionGroup>
  <Accordion title="Users cannot access the deployment">
    * Ensure the Auth Wall is enabled and the user is added to the authorized users list
    * Verify that the user is logging in with the correct credentials
    * Check if the user's session has expired (24-hour limit)
    * Try clearing browser cookies and logging in again
  </Accordion>

  <Accordion title="Deployment is still public">
    * Check the protection scope. If "Protect only deployment previews" is selected, published deployments will remain public
    * Ensure the Auth Wall is enabled and the settings have been saved
    * Verify you're accessing the correct environment
  </Accordion>

  <Accordion title="Changes not applied">
    * Make sure to click the **Save** button after making changes to the Auth Wall settings
    * Refresh the page to see if settings were saved
    * Check browser console for any errors
  </Accordion>

  <Accordion title="Session expires too quickly">
    * Sessions last for 24 hours by default
    * User must log in again after session expiration
    * This is by design for security purposes
  </Accordion>
</AccordionGroup>

## Security Considerations

* **Not a replacement for app-level security** - Auth Wall protects access to deployments, but your application should still implement its own authentication and authorization
* **Password security** - Passwords are encrypted and stored securely
* **Session security** - Sessions are managed server-side and cannot be easily hijacked
* **IP logging** - Last login information helps track access patterns
* **Immediate revocation** - Removing users takes effect immediately for new requests