c294e9b2cb
# Description of Changes Fixes share-link navigation for SSO users. Reported on v2.9.2 with `SSOAutoLogin: true`: clicking a `/share/<token>` link in an email redirected the user to the home page after SSO instead of the shared file. ## Root cause Three compounding issues had to be fixed together; the first was the initial symptom but the other two only surfaced during live verification. 1. **Spring Security blocked `/share/<token>` for unauthenticated users.** The route wasn't in `RequestUriUtils.isPublicAuthEndpoint`, so the server 302'd straight to `/login` before React could load `ShareLinkPage`. The share URL was lost because `NullRequestCache` is configured and never persisted the original destination. 2. **`httpErrorHandler` full-page-redirected to `/login?from=<path>` on any unhandled 401** (fired by `LicenseContext`, `AppConfig`, etc. during normal ShareLinkPage mount). That *did* preserve the return path — but **Spring Security strips query strings from `/login`** (302 to bare `/login`), so `?from=` never reached React. Confirmed via `curl -i http://localhost:8080/login?from=xyz` → `Location: /login`. 3. **`AuthCallback.tsx` unconditionally `navigate("/")`** after the SAML/OAuth round-trip, discarding any intended destination. ## Fix **Backend** — make `/share/<token>` a public SPA bootstrap, data APIs stay protected: - `RequestUriUtils.isPublicAuthEndpoint` — permits `^/share/[^/]+/?$` (tight regex, single token segment only; `/share/<token>/anything` stays protected). - `ReactRoutingController` — dedicated `@GetMapping("/share/{token}")` mirroring `/auth/callback`. - `/api/v1/storage/share-links/**` remains behind Spring Security with its existing `canAccessShareLink` check. **Frontend** — persist the return path across full-page redirects via `sessionStorage` (same-origin, survives the SSO round-trip): - `httpErrorHandler.ts` — stashes current pathname to `stirling_post_login_path` before the 401 → `/login` redirect. - `springAuthClient.ts` — new `isSafePostLoginRedirect` / `setPostLoginRedirectPath` / `consumePostLoginRedirectPath` helpers (rejects protocol-relative URLs and auth-plumbing paths to guard against open-redirect abuse). - `Login.tsx` — on explicit user sign-in, read path from `location.state` or `?from=` query and stash it; don't clobber an already-stashed value. - `AuthCallback.tsx` — consume the stashed path (single-use) and `navigate(target)` instead of always `/`. --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. --------- Co-authored-by: EthanHealy01 <[email protected]>
Frontend
All frontend commands are run from the repository root using Task:
task frontend:dev— start Vite dev server (localhost:5173)task frontend:build— production buildtask frontend:test— run teststask frontend:test:watch— run tests in watch modetask frontend:lint— run ESLint + cycle detectiontask frontend:typecheck— run TypeScript type checkingtask frontend:check— run typecheck + lint + testtask frontend:install— install npm dependencies
For desktop app development, see the Tauri section below.
Environment Variables
The frontend requires environment variables to be set before running. task frontend:dev will create a .env file for you automatically on first run using the defaults from config/.env.example - for most development work this is all you need.
If you need to configure specific services (Google Drive, Supabase, Stripe, PostHog), edit your local .env file. The values in config/.env.example show what each variable does and provides sensible defaults where applicable.
For desktop (Tauri) development, task desktop:dev will additionally create a .env.desktop file from config/.env.desktop.example.
Docker Setup
For Docker deployments and configuration, see the Docker README.
Tauri
All desktop tasks are available via Task. From the root of the repo:
Dev
task desktop:dev
This ensures the JLink runtime and backend JAR exist (skipping if already built), then starts Tauri in dev mode.
Build
task desktop:build
This does a full clean rebuild of the backend JAR and JLink runtime, then builds the Tauri app for production.
Platform-specific dev builds are also available:
task desktop:build:dev # No bundling
task desktop:build:dev:mac # macOS .app bundle
task desktop:build:dev:windows # Windows NSIS installer
task desktop:build:dev:linux # Linux AppImage
JLink Tasks
You can also run JLink steps individually:
task desktop:jlink # Build JAR + create JLink runtime
task desktop:jlink:jar # Build backend JAR only
task desktop:jlink:runtime # Create JLink custom JRE only
task desktop:jlink:clean # Remove JLink artifacts
Clean
task desktop:clean
Removes all desktop build artifacts including JLink runtime, bundled JARs, Cargo build, and dist/build directories.
Note
Desktop builds require additional environment variables. See Environment Variables above -
task desktop:devwill set these up automatically fromconfig/.env.desktop.exampleon first run.