# Check How Filevine Handles Authentication

Since no tokens are in localStorage, Filevine might be using:
1. **Cookies** (including HTTP-only cookies we can't read)
2. **Request headers** (Authorization header sent with each request)
3. **Session-based auth** (server-side sessions)

## Step 1: Check Network Requests

1. Open DevTools → Network tab
2. Filter by "XHR" or "Fetch"
3. Click on any API request (like `/api/orgs` or `/api/projects`)
4. Check the **Request Headers**:
   - Look for `Authorization: Bearer ...`
   - Look for `Cookie: ...`
   - Look for any custom headers like `x-fv-*`

## Step 2: Check Cookies

Run this in the Filevine page console:

```javascript
// Check all cookies
console.log('=== Cookies ===');
document.cookie.split(';').forEach(cookie => {
  const [name, value] = cookie.trim().split('=');
  if (name.toLowerCase().includes('token') || 
      name.toLowerCase().includes('auth') || 
      name.toLowerCase().includes('session') ||
      name.toLowerCase().includes('fv')) {
    console.log(name, value ? value.substring(0, 50) : '');
  }
});

// Check all cookies (full list)
console.log('\n=== All Cookies ===');
console.log(document.cookie);
```

## Step 3: Check Network Request Headers

In DevTools → Network tab:
1. Find a request to `api.filevineapp.com` or `product.filevineapp.com`
2. Click on it
3. Go to "Headers" tab
4. Look at "Request Headers"
5. Check for:
   - `Authorization: Bearer <token>`
   - Any `x-fv-*` headers
   - `Cookie` header

## Step 4: Intercept Authorization Headers

If tokens are in request headers, we need to intercept them differently. The updated interception script should catch this, but we might need to also check outgoing requests.

## What to Report

Please share:
1. What do you see in the Network tab → Request Headers for API calls?
2. Any cookies found?
3. Do you see `Authorization: Bearer ...` headers?

This will help us understand how Filevine actually handles authentication.
