Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic Access-Control-Expose-Headers Support #27

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

yinheli
Copy link

@yinheli yinheli commented Sep 4, 2024

Add Dynamic Support for Access-Control-Expose-Headers

This PR implements dynamic support for the Access-Control-Expose-Headers header in php-cors, addressing the need for more flexible CORS header management in complex applications.

Proposal issue: #29

Changes

  • Update CorsService to merge existing exposed headers with configured
  • Add deduplication for exposed headers

Benefits

  • Allows developers to set exposed headers dynamically at the controller or middleware level.
  • Provides greater flexibility for applications with diverse API endpoints requiring different header exposures.
  • Maintains backwards compatibility with existing global configuration.

Testing

I've added new unit tests to cover.

Feedback and suggestions are welcome. Thank you!

- Update CorsService to merge existing exposed headers with configured
- Add deduplication for exposed headers

fruitcake#29
@yinheli yinheli force-pushed the feature/dynamic-access-control-expose-headers branch from f3ef5d4 to 43c705a Compare September 11, 2024 08:50
@yinheli yinheli changed the title Enhance CORS exposed headers handling for dynamic response (#26) Dynamic Access-Control-Expose-Headers Support Sep 11, 2024
@barryvdh
Copy link
Member

What would be the use-case of adding these headers in the controller or middleware?

@yinheli
Copy link
Author

yinheli commented Nov 15, 2024

Here are some common use cases for dynamically adding Access-Control-Expose-Headers in controllers or middleware:

  1. Custom Pagination Headers
  • When specific API endpoints need to expose pagination headers like X-Total-Count, X-Page-Count
  • These headers may only be relevant for paginated list endpoints, not needed globally
  1. API Version Headers
  • Exposing version headers (X-API-Version) only for versioned API routes
  • Keeping header exposure scoped to relevant endpoints
  1. Resource-Specific Headers
  • Custom headers like X-Resource-ID, X-Last-Modified for specific resources
  • No need to expose these headers on all routes
  1. Authentication/Authorization Headers
  • Selectively exposing auth-related headers (X-Token-Expiry, X-Refresh-Token)
  • Only needed on auth-related endpoints
  1. Rate Limiting Headers
  • Headers like X-RateLimit-Remaining for rate-limited endpoints
  • Not applicable to all routes

This dynamic approach allows applications to:

  • Keep CORS header exposure minimal and relevant
  • Avoid exposing unnecessary headers globally
  • Have fine-grained control per route/controller
  • Improve security by limiting header exposure

The proposed implementation provides this flexibility while maintaining backwards compatibility with global configuration.

Imagine that if you are maintaining a large monolithic application, you wouldn't want the CORS middleware configuration to affect many routes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants