Main Issues Fixed:
1. Tools Disabled on Initial Login (Required Page Refresh)
Problem: After successful login, all PDF tools appeared grayed
out/disabled until the user refreshed the page.
Root Cause: Race condition where tools checked endpoint availability
before JWT was stored in localStorage.
Fix:
- Implemented optimistic defaults in useEndpointConfig - assumes
endpoints are enabled when no JWT exists
- Added JWT availability event system (jwt-available event) to notify
components when authentication is ready
- Tools now remain enabled during auth initialization instead of
defaulting to disabled
2. Session Lost on Page Refresh (Immediate Logout)
Problem: Users were immediately logged out when refreshing the page,
losing their authenticated session.
Root Causes:
- Spring Security form login was redirecting API calls to /login with
302 responses instead of returning JSON
- /api/v1/auth/me endpoint was incorrectly in the permitAll list
- JWT filter wasn't allowing /api/v1/config endpoints without
authentication
Fixes:
- Backend: Disabled form login in v2/JWT mode by adding && !v2Enabled
condition to form login configuration
- Backend: Removed /api/v1/auth/me from permitAll list - it now requires
authentication
- Backend: Added /api/v1/config to public endpoints in JWT filter
- Backend: Configured proper exception handling for API endpoints to
return JSON (401) instead of HTML redirects (302)
3. Multiple Duplicate API Calls
Problem: After login, /app-config was called 5+ times,
/endpoints-enabled and /me called multiple times, causing unnecessary
network traffic.
Root Cause: Multiple React components each had their own instance of
useAppConfig and useEndpointConfig hooks, each fetching data
independently.
Fix:
- Frontend: Created singleton AppConfigContext provider to ensure only
one global config fetch
- Frontend: Added global caching to useEndpointConfig with module-level
cache variables
- Frontend: Implemented fetch deduplication with fetchCount tracking and
globalFetchedSets
- Result: Reduced API calls from 5+ to 1-2 per endpoint (2 in dev due to
React StrictMode)
Additional Improvements:
CORS Configuration
- Added flexible CORS configuration matching SaaS pattern
- Explicitly allows localhost development ports (3000, 5173, 5174, etc.)
- No hardcoded URLs in application.properties
Security Handlers Integration
- Added IP-based account locking without dependency on form login
- Preserved audit logging with @Audited annotations
Key Code Changes:
Backend Files:
- SecurityConfiguration.java - Disabled form login for v2, added CORS
config
- JwtAuthenticationFilter.java - Added /api/v1/config to public
endpoints
- JwtAuthenticationEntryPoint.java - Returns JSON for API requests
Frontend Files:
- AppConfigContext.tsx - New singleton context for app configuration
- useEndpointConfig.ts - Added global caching and deduplication
- UseSession.tsx - Removed redundant config checking
- Various hooks - Updated to use context providers instead of direct
fetching
---------
Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: stirlingbot[bot] <stirlingbot[bot]@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Ludy <Ludy87@users.noreply.github.com>
Co-authored-by: EthanHealy01 <80844253+EthanHealy01@users.noreply.github.com>
Co-authored-by: Ethan <ethan@MacBook-Pro.local>
Co-authored-by: Anthony Stirling <77850077+Frooodle@users.noreply.github.com>
Co-authored-by: stirlingbot[bot] <195170888+stirlingbot[bot]@users.noreply.github.com>
Co-authored-by: ConnorYoh <40631091+ConnorYoh@users.noreply.github.com>
Co-authored-by: Connor Yoh <connor@stirlingpdf.com>
# Description of Changes
TLDR:
- Introduced a new "Convert to CMYK" option in Replace Color settings.
- Added tooltips for the new CMYK conversion feature.
- Updated ReplaceColorParameters to support COLOR_SPACE_CONVERSION
option.
For backend reference see this PR: #4494
This pull request adds support for converting PDF colors to the CMYK
color space in the Replace Color tool, which is especially useful for
preparing documents for professional printing. The changes include
updates to the user interface, tooltips, and type definitions to
accommodate this new option.
**Replace Color tool: Add CMYK color space conversion option**
* Feature addition:
* Added a new `COLOR_SPACE_CONVERSION` option to the
`replaceAndInvertOption` parameter in the `ReplaceColorParameters` type,
enabling support for CMYK color conversion.
* Updated the `ReplaceColorSettings` component to include "Convert to
CMYK" as a selectable option in the UI.
* User guidance:
* Added a new tooltip entry explaining the "Convert to CMYK" feature,
describing its purpose and use case for professional printing.
### Front-end
<img width="642" height="994" alt="image"
src="https://github.com/user-attachments/assets/fa1df879-f157-45ca-9865-238238afc093"
/>
<!--
Please provide a summary of the changes, including:
- What was changed
- Why the change was made
- Any challenges encountered
Closes #(issue_number)
-->
---
## Checklist
### General
- [x] I have read the [Contribution
Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md)
- [x] I have read the [Stirling-PDF Developer
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/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)
- [x] I have performed a self-review of my own code
- [x] 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)
- [x] Screenshots or videos demonstrating the UI changes are attached
(e.g., as comments or direct attachments in the PR)
### Testing (if applicable)
- [x] I have tested my changes locally. Refer to the [Testing
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing)
for more details.
---------
Signed-off-by: Balázs Szücs <bszucs1209@gmail.com>
# Description of Changes
Please provide a summary of the changes, including:
## Add PDF File Association Support for Tauri App
### 🎯 **Features Added**
- PDF file association configuration in Tauri
- Command line argument detection for opened files
- Automatic file loading when app is launched via "Open with"
- Cross-platform support (Windows/macOS)
### 🔧 **Technical Changes**
- Added `fileAssociations` in `tauri.conf.json` for PDF files
- New `get_opened_file` Tauri command to detect file arguments
- `fileOpenService` with Tauri fs plugin integration
- `useOpenedFile` hook for React integration
- Improved backend health logging during startup (reduced noise)
### 🧪 **Testing**
See
* https://v2.tauri.app/start/prerequisites/
*
[DesktopApplicationDevelopmentGuide.md](DesktopApplicationDevelopmentGuide.md)
```bash
# Test file association during development:
cd frontend
npm install
cargo tauri dev --no-watch -- -- "path/to/file.pdf"
```
For production testing:
1. Build: npm run tauri build
2. Install the built app
3. Right-click PDF → "Open with" → Stirling-PDF
🚀 User Experience
- Users can now double-click PDF files to open them directly in
Stirling-PDF
- Files automatically load in the viewer when opened via file
association
- Seamless integration with OS file handling
---
## 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/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/HowToAddNewLanguage.md#add-new-translation-tags)
(for new translation tags only)
### 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 tested my changes locally. Refer to the [Testing
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing)
for more details.
---------
Co-authored-by: Connor Yoh <connor@stirlingpdf.com>
Co-authored-by: James Brunton <james@stirlingpdf.com>
Co-authored-by: James Brunton <jbrunton96@gmail.com>
# Description of Changes
Remove path aliases from self folder (e.g. remove `@core` from
`tsconfig.core.json`). It's not necessary and using it means that it's
impossible for the other folders to override the behaviour. The only
reason we should currently be using `@core` is in `proprietary` where we
need to explicitly import the `core` version of the thing we're
overriding so that we can re-expose or use the objects.
# Description of Changes
Add linting to ensure correct imports style is used.
I've disabled the linting for two imports which use relative paths
because the files they're importing are siblings to core and
proprietary. They could probs be imported by `@app/../assets/xxx` but it
seems silly. The other thing we could do is add an explicit `@assets`
path alias or something, but it seemed more complex than just disabling
the lint for those two imports at this stage. We could always do it in
the future if we want to import stuff up there a lot in the future.
Adds granular privacy controls for analytics - splits single
enableAnalytics toggle into separate PostHog and Scarf controls with
improved admin
UX.
Backend Changes
Configuration (ApplicationProperties.java)
- Added enablePosthog and enableScarf boolean fields
- New methods: isPosthogEnabled(), isScarfEnabled() (null = enabled when
analytics is on)
Services
- PostHogService: Now checks isPosthogEnabled() instead of
isAnalyticsEnabled()
- ConfigController: Exposes new flags via API
- SettingsController: Changed endpoint from @RequestBody to
@RequestParam
Frontend Changes
Architecture
- Converted useAppConfig hook → AppConfigContext provider for global
access
- Added refetch() method for config updates without reload
New Features
1. AdminAnalyticsChoiceModal: First-launch modal when enableAnalytics
=== null
- Enable/disable without editing YAML
- Includes documentation link
2. Scarf Tracking System: Modular utility with React hook wrapper
- Respects config + per-service cookie consent
- Works from any code location (React or vanilla JS)
3. Enhanced Cookie Consent: Per-service toggles (PostHog and Scarf
separate)
Integration
- App.tsx: Added AppConfigProvider + scarf initializer
- HomePage.tsx: Shows admin modal when needed
- index.tsx: PostHog opt-out by default, service-level consent
Key Benefits
✅ Backward compatible (null defaults to enabled)
✅ Granular control per analytics service
✅ First-launch admin modal (no YAML editing)
✅ Privacy-focused with opt-out defaults
✅ API-based config updates
---------
Co-authored-by: Connor Yoh <connor@stirlingpdf.com>
