Skip to content

Conversation

@jwm4
Copy link
Contributor

@jwm4 jwm4 commented Sep 26, 2025

Gordon Sim pointed out on Slack:

serving over HTTP when using your own access token seems dangerous without very tight control over who can access your http endpoint. Would be better to require the token to be passed a s a bearer token when running over http.

This is a good point. This PR addresses this in the following way:

  • If running in stdio mode, it still uses the JIRA_API_TOKEN environment variable as it always has. I tested this with Cursor and it still works.
  • If running in SSE or Streamable HTTP, it ignores the JIRA_API_TOKEN environment variable if any. Instead it checks to to see if the calling application has sent it a token. If it has, it uses that token. I tested it with both SSE and Streamable HTTP (using Llama Stack), and it works correctly if you send it a valid token. If you send it an invalid token or no token, that information goes to the model to formulate a reasonable response, e.g., Response content: It seems that I do not have the necessary permissions to access the details of the Jira issue RHAISTRAT-24. You may need to log in to the appropriate Jira account with the required permissions to view this issue.
  • The README is updated with details about why and how to send an API token to the server.

@jwm4
Copy link
Contributor Author

jwm4 commented Oct 9, 2025

@simonbaird , can you review this? I got it merged with the latest changes and the CI is passing now.

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.

1 participant