nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Atlassian CLI - Issue logging in

J. Caldwell

I'm playing around with the CLI that Bob Swift wrote. I'm having a basic fail with logging in. It looks like it is a problem with special charcters in my password. When I have one with no special charcters, it works, when I have one with special charcters it bombs out with a "Cause: com.atlassian.jira.rpc.exception.RemoteAuthenticationException: Invalid username or password." I've tried multiple of the escape charcters I know of to try to escape the special charcters in the password string. How do I escape the charcter?

Accepted answers

Bob Swift

On later releases (2.6.0 and later), most cases of special characters in passwords have been resolved although it is still best to avoid if possible. Open an issue with the details and I can investigate. Special characters can also cause problems if they special meaning for the command shell. Double quote strings containing special characters to help.

All comments

Bob Swift

Matt Geis

What about a double-quote inside an argument (for example, adding a comment to an issue, and the comment body contains a double quote)? This actually causes an error. I tried escaping it (in a way the the shell would allow -- basically putting a backslash in front of the quote -- but I still get the error.

What's the right way to handle a double quote inside an arg in the CLI?

Bob Swift

I have updated the tips section to be clearer on this, but escaping should work on most OS environments. Doubling the double quote will also work on many OS environments except Windows.

Bob Swift

I have updated the tips section to be clearer on this, but escaping should work on most OS environments. Doubling the double quote will also work on many OS environments except Windows.

Matt Geis

Thanks for the quick reply, Bob.

Looking at the error message I was getting, it appeared that the doWork() method that takes a String tries to tokenize it and escape special characters, and while the string I generated worked just fine on the real command-line, it failed in the java client.

Because the tokens it generated looked a bit off, I tried using the doWork() that takes a String[] (the list of args), and that approach worked just fine. It allowed the JiraClient to do the escaping knowing that the args had already been correctly separated.