setpassword of new user account fails

[tlmueller]

After creating a new user for Helpdesk, the user receives an email to activate the account.

When trying to save the new real name and password I get an error message, that the post link cannot be opened

com.atlassian.analytics.analytics-client:js-events.js:9 POST https://domain.tld/servicedesk/customer/portal/1/user/setpassword 400 ()

[Andy Heinzer]

I wanted to circle back to this community thread.  In our support case we found the problem was not about proxy settings in Jira, but rather in relation to the use of a password policy in Jira. 

When any password policy has been enabled in Jira, and the user's password does not meet the password complexity, the user will not be able to continue to setup there account.  We found in a HAR file the response in a json format of:

{"errors":[],"reasonKey":"The password must satisfy the password policy","reasonCode":"400"} 

However this error does not appear on the page for the end user to see, and unless to dig deeply into the browser console to find that error, there is no indication to the end user why this failed.

To address that problem we have created a new bug over in https://jira.atlassian.com/browse/JSDSERVER-5786

I would recommend that other users that might come across this problem please follow that bug ticket for further updates to this.

Regards,

Andy

[tlmueller]

Hi Andrew,

thank you very much for your reply.

We are running Jira on a Linux-based system with nginx reverse proxy. But even when I open the url directly with the jira port https://domain.tld:8080/servicedesk/customer/portal/1/user/setpassword I get the message that the url does not exist.

When I add a new user to the Jira ServiceDesk, the user receives an email to add the full name and password. Because this form uses the link above, the form cannot be processed.

[Andy Heinzer]

Ah, ok.  So when Jira sends email notifications, the link it uses in those notfications for the site is defined in the Base URL in the system admin panel of Jira.  Configuring the Base URL explains how to do this within Jira:

You need to have the system administrator global permission in order to perform this function.

To configure the Base URL:

1. Choose  > System. 
2. Choose General Configuration in the left-hand panel.
3. Choose Edit Settings.
4. Enter the new URL in the Base URL text box.
5. Choose Save.

If the site is using https, I would not expect it to use port 8080 or port 80.  Instead we would expect this to use the default HTTPS port of 443 or possibly another port like 8443.   Since the emails are using the link https://domain.tld:8080  I am confident the Base URL is currently set to this.  However this might not be how most other users access this Jira site.   Ideally we want to set the Base URL to be the public facing address for the site.  Which I think would be either something like http://jira.example.com or https://jira.example.com

However just because you set a value in the Base URL setting of Jira does not necessarily make your site accessible on that address.  This setting is more of a way to tell the application (Jira) what URL your end users are utilizing to reach the application.

It sounds like the source of the problem here is that the site is not really accessible at the URL being requested.

I understand you're using nginx with Jira, can you tell me where SSL is being terminated here?  Is it on Nginx, on Jira's Tomcat container, or both?

I would also be interested to learn what settings you have in your $JIRAINSTALL/conf/server.xml file.  This file tells us how Jira is setup to serve it's content using it's Tomcat instance.   In cases where a reverse proxy sits in front of Jira, I would expect that you would have a dedicated <connector> tag in that config file that explains the port number Tomcat/Jira is using, but in addition to this we should probably also see proxyName, proxyPort, and scheme parameters defined as per Integrating JIRA with Nginx.

[tlmueller]

Hi Andrew,

here we are:

server.xml

<Service name="Catalina">

<Connector port="18080"

maxThreads="150"
minSpareThreads="25"
connectionTimeout="20000"

enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"
bindOnInit="false"
proxyName="domain.tld.net"
proxyPort="443"
scheme="https"
/>

nginx config (in Plesk)

location ~ / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://domain.tld.net:18080;
client_max_body_size 10M;
}

I don't know whether it has something to do with the configuration.

I tried the following:

1. Open a Jira ServiceDesk project
2. Open section "customers"
3. Click on "add customers"
4. Click on button "Add e-mail address"
5. The new customer receives an e-mail to activate the account
6. The new customer clicks no the activation link
7. The user has to type in the full name and a password
8. When clicking on "Save and continue" nothing happens, because the route (post method) https://domain.tld/servicedesk/customer/portal/1/user/setpassword is not available. 

Thanks a lot for your assistance,

Timo 

[Andy Heinzer]

Hi Timo,

I can't see any clear problems here.  The browser console seems to be calling a site of https://su batch.js which I know can't be correct, but perhaps the image has been altered here.

To further our troubleshooting of this problem, I created a support request and asked you there for a number of items, logs, HAR file, and some other steps to take to try to better understand the cause of this problem here.  You can find this support ticket by going to https://getsupport.atlassian.com/servicedesk/customer/portal/3/SDS-32205

Regards,

Andy

[Andy Heinzer]

Hi Timo,

This appears to be an HTTP 400 error, which just tell us this is a bad request.   I suspect this could be cause either by the specific URL being referenced here, and/or the payload being sent/received.   Usually when I see these kinds of errors, it tends to be because there is a proxy, firewall, or some other layer between Jira and the outside connections that reach Jira.   I would expect that this could be cause by a misconfiguration either on the proxy side or possibly within Jira's own server.xml that dictates how Jira's Tomcat instance serves up the website. 

Are you by chance using a windows based proxy with Jira?  If so I would recommend reviewing these two KB articles:

https://confluence.atlassian.com/jirakb/jira-elements-fail-to-render-with-http-400-error-860033769.html

and

https://confluence.atlassian.com/jirakb/jira-functionality-fails-due-to-http-400-bad-request-error-770015587.html

They describe two different possible problems on a Windows based proxy like IIS that could cause certain functionality like this to fail and generate 400 errors like this.  

If neither of these apply, please let me know more about your environment here in regards to your version of Jira and your network setup in regards to how Jira is being served up in your environment (e.g.: proxy, load balancer, or is Jira directly exposed to the outside network).