Apologies
When configuring JIRA service desk it appears that the baseURL is not updated in the service desk queues as the http:// appears to not be read from the baseURL value stored by JIRA in the config pages of the application.
As a consequence the service desk queues do not work as they make illegal calls to http://baseURL URLs instead of the expected https://
this triggers the CRSF engine and the page object fails.
how can I fix this
I am using apache to provide the SSL and proxying the requests back to JIRA
That sounds broken to me - you're saying the base url in JIRA is set to https://base but Service Desk queues are linking to something different? Is that right?
Is it just the queues, or are there other places in Service Desk?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes the main JIRA application seems to work fine, but the service desk queue portly makes calls to the rest api over http and and these break the functionality
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hmm. It should be using a single base-url from the config, I'm not sure what the "variable" here is, unless it's something in the environment which it being inherited. Is that possible?
The other thought is maybe the proxy is doing something odd, like rewriting the urls. I'd want to test a service desk queue usage without going through the proxy to see what url gets used then, but I understand that might be quite difficult. Do you have access to the proxy settings?
If it's not an environment or proxy setting, then it sounds very much like a bug to me!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
yes I do and the proxy is correctly set as it works fine for static content and also for the main application.
The apache proxy is application agnostic.
I will update the question once I have an answer
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, I mentioned the proxy because I got one wrong once and it did something similar to this with an add-on that grabbed data via REST. I'd got it proxying https://site to https://internalserver, when I should have had https://site to http://internalserver (offloading SSL to the proxy). But it is a long-shot, as there were other symptoms I'd expect you to have seen (dashboards as well as queues referring to the wrong url)
Hopefully we'll get an answer from support soon!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I think we're missing a question here?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.