feat: Implement Shotgrid authentication with username/password

[aviralgarg05]

PR Description: Implement ShotGrid User Authentication Flow

Summary

This PR implements a robust user authentication flow for the DNA application, moving away from static script-based authentication to a dynamic, user-specific session token mechanism using ShotGrid's native authentication.

Changes

Backend (dna-backend)

• ShotgridProvider Enhancements:
  • Updated constructor to support session_token.
  • Implemented authenticate_user static method to validate credentials and retrieve a ShotGrid session token.
  • Added get_user_by_login for post-auth user detail retrieval.
• API Overhaul (main.py):
  • Introduced POST /auth/login endpoint to handle user credentials.
  • Updated dependency injection (ProdtrackProviderDep) to extract Bearer tokens from the Authorization header, enabling authenticated stateful sessions for all entity requests.
• Provider Base: Added abstract methods to ProdtrackProviderBase to maintain parity across potential future providers.

Frontend (dna-frontend)

• ApiHandler Update:
  • Added login() method to the core API layer.
  • Integrated request interceptors to automatically attach the stored session token to all outgoing requests.
• ProjectSelector Component:
  • Added a Password input field to the initial login screen.
  • Implemented handleLogin logic to manage the transition from credentials to active session.
  • Added Session Persistence: Tokens and user emails are now safely stored in localStorage and restored on application load, preventing unnecessary re-logins.

Verification Results

• Authentication: Verified that the backend correctly validates ShotGrid credentials and returns a valid session token.
• Session Management: Confirmed that the frontend correctly stores the token and includes it in subsequent API calls (e.g., fetching projects/playlists).
• Persistence: Validated that refreshing the page maintains the user's login state and selected project/playlist.

Technical Notes

• The login flow now returns the user's email address upon successful authentication, which is used to bootstrap the project selection process.
• Stub user IDs are currently used where the API expects an ID but only a login is available; this can be refined as the user model matures.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: aviralgarg05 / name: Aviral Garg (0d78417, 3b04d3e, 3f5130a, a8dc9d4)

[jspada200]

We do store the prodtrack provider in a lru cache at the moment. We probably want to instantiate it on each request using the authorization creds provided on each request. We can probably do something clever with fastapi middleware so we always get a new provider logged in with each request.

[jspada200]

Thank you so much for taking this on! Do you need a sg instance to test?

[aviralgarg05]

Thanks! I don't need a ShotGrid instance. I've refactored the code to move the authentication logic into the provider and cleaned up the implementation as requested. It should be ready for review.

[jspada200]

You can fix the formatting using the make commands in the repo.

[jspada200]

I am having some trouble getting this to work. The reason being is that we assumed that we would be able to use the traditional method of logging into SG which is what is done here. However, it seems that since Shotgrid (Flow) transitioned to cloud, they have moved to SSO through Autodesk's identity services.

I think the solution here may be to move the logic you wrote to login into another kind of provider "ShotgridAuthenticationProvider" to support on prem instances, which can injected into the ShotgridProvider and implement SSO flow in another kind of authentication provider.

Let me know if you want to continue this as it got more complicated or if I need to spin up another ticket for SSO login.

[aviralgarg05]

I am having some trouble getting this to work. The reason being is that we assumed that we would be able to use the traditional method of logging into SG which is what is done here. However, it seems that since Shotgrid (Flow) transitioned to cloud, they have moved to SSO through Autodesk's identity services.

I think the solution here may be to move the logic you wrote to login into another kind of provider "ShotgridAuthenticationProvider" to support on prem instances, which can injected into the ShotgridProvider and implement SSO flow in another kind of authentication provider.

Let me know if you want to continue this as it got more complicated or if I need to spin up another ticket for SSO login.

I've implemented the separation of concerns by creating ShotgridAuthenticationProvider. This keeps the main application logic decoupled and clean, and should make it easier to add SSO or other auth providers in the future without touching the core API. I'm happy to continue with this approach!

[jspada200]

I am having some trouble getting this to work. The reason being is that we assumed that we would be able to use the traditional method of logging into SG which is what is done here. However, it seems that since Shotgrid (Flow) transitioned to cloud, they have moved to SSO through Autodesk's identity services.
I think the solution here may be to move the logic you wrote to login into another kind of provider "ShotgridAuthenticationProvider" to support on prem instances, which can injected into the ShotgridProvider and implement SSO flow in another kind of authentication provider.
Let me know if you want to continue this as it got more complicated or if I need to spin up another ticket for SSO login.

I've implemented the separation of concerns by creating ShotgridAuthenticationProvider. This keeps the main application logic decoupled and clean, and should make it easier to add SSO or other auth providers in the future without touching the core API. I'm happy to continue with this approach!

Lets keep this simple and worry about SSO later. Can test by setting a password on the SG site I think.

[jspada200]

Once logged it, the session token should be set on all the outbound requests. How are you testing all this logic? Do you have a SG instence running?

[aviralgarg05]

Hi,

1. Token Persistence: We've got an Axios interceptor on the frontend that automatically adds the session token to the Authorization header for all requests after login. The backend picks this up and uses it to initialize the ShotGrid session for that specific request.
2. Testing: No live SG instance in the test suite—we're mocking the Shotgun API to keep tests fast and reliable. I did verify it against a real instance during development though!

Let me know if you want to see more specific unit tests for this!