Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #22062

Closed (moved)
Open
Opened Apr 25, 2017 by cypherpunks@cypherpunks

Bad requests do not add the Access-Control-Allow-Origin header

I've found this issue by submitting invalid requests through Atlas. For example, https://atlas.torproject.org/#search/%3Ctest%3E shows in the Firefox Developer Tools Console tab the following message.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://onionoo.torproject.org/summary?search=%3Ctest%3E. (Reason: CORS header 'Access-Control-Allow-Origin' missing).

Looking at the Onionoo code, the culprit seems to be the doGet function and more specifically ResourceServlet.java:356 which sets several headers but only when the request has been processed successfully. For invalid requests it calls sendError. According to the Java API sendError

Sends an error response to the client using the specified status code and clears the buffer. The server will preserve cookies and may clear or update any headers needed to serve the error page as a valid response. If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page I'm not sure which headers sendError clears or updates but I think the setHeader calls can safely be moved to the top of the doGet function to ensure these headers are also included in bad request responses. Unfortunately i have no setup to test this assumption/solution.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#22062