Hello,
I am trying to access JRA API's on a locally hosted JIRA server using javascript. But i do get a 401 error even passing the basic authentication parameters. Can you help me to understand if this authentication method does not work anymore.
I understand for a cloud hosted JIRA, we need a API token but for locally hosted i do not think it is needed.
Thanks for your support.
Hello Earl,
Thanks for the reply.
Unfortunately it does not work and throws and 401 error even after trying the two methods. I am requesting the API using jQuery Ajax Get passing the below data in the header.
1. Basic authorization "Basic base64_String(username:password)".
2. Basic authorization "Basic base64_String(email:password)".
Both throws unauthorised error 401.
Thanks for your support.
Hello,
Thanks for the additional info, and it sounds like there is more than likely an issue with the base64 encoded string. I know there are some issues in running a base64 encoding command where the line breaks are included in the output of the encoded string without using modifiers to remove the line breaks.
What format are you using in your command to do the base64 encode to the user name and password?
As an exe the following two options can be used on a mac or linux system to generate a base64 encoded string in the correct format:
echo -n exampleuser@example.com:password | openssl base64 | tr -d '\n'
OR
echo -n exampleuser@example.com:password | base64
and on Windows 7 or later:
$Text = ‘exampleuser@example.com:password’
$Bytes = [System.Text.Encoding]::UTF8.GetBytes($Text)
$EncodedText = [Convert]::ToBase64String($Bytes)
$EncodedText
Regards,
Earl
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Earl,
I tried using the encoded string from the above, but still it throws "401 Error".
I use ajax call like below,
jQuery.ajax({
url: getStoriesUrl,
headers: {
'Authorization': 'Basic String64',
'Content-Type': 'application/json',
'Access-Control-Allow-Origin': '*'
},
success: function (result) {
console.log(result);
},
failure: function (error) {
console.log(error);
},
});
Thanks for your support
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello,
So first and foremost the bas64 encoded string can be decoded, so if that is a production username and password make sure to change it to be on the safe side as this is a public forum, and that value will have been indexed by google analytics.
Running it through a decode though I am seeing some conflicts on the last character, Base64 is supposed to be an even multiple of 4 encoded characters, where = is generally used to pad the output if it's output is short of that grouping. and your string is short of the desired grouping and is not padded.
The last MD you have in your output encoded string looks like it is half of a MD== (for appropriate padding) which would decode to a 0 as the last character, BUT Referencing this List of encoding comparisons, MD== is not present and MA== would be the appropriate decode for a 0, BUT base64 will default to 0 for unknown variables.
Because of the default to 0 option, Decoding the MD== padded encoding will give the 0 as the last character BUT re-encoding the same string that was output you get the proper encoded 0 string padding and you will see a MA== as the last 4 characters, so it looks like there is something erring in the last character of the encoded variable and its defaulting to a 0 when unknown.
exe:
echo -n dWliNTM3NjE6Q29udGluZW50YWwyMD | base64 --decode
uib53761:Continental2
echo -n uib53761:Continental2 | base64
dWliNTM3NjE6Q29udGluZW50YWwy
echo -n dWliNTM3NjE6Q29udGluZW50YWwyMD== | base64 --decode
uib53761:Continental20
echo -n uib53761:Continental20 | base64
dWliNTM3NjE6Q29udGluZW50YWwyMA==
So there is defiantly something wrong with the input of the data into the encoding command, possibly there is a variable that is not a standard UTF-8 encoding from a copy paste of the variable from a source location that altered the binary value in the background. I would say first reset the Password, then manually type in the username and password to the input for the encoding to see if the behavior changes.
Regards,
Earl
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Earl,
The string sent to you is definitely not the real one. It’s a random string. Just for example I used.
To make it simple to understand, you can as well edit your last reply. But for sure encoding and decoding the actual pair is always returning the correct values.
but still does not work. 😞
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello,
That is correct on a Locally hosted install the API token is not something you need to look at, it only applies to the Cloud platform.
Some Example calls and getting started documentation can be found here:
and a quick EXE on a basic API call using curl from the command line would be the following format to do a GET on all permissions:
curl -D- -u username:password -X GET "http://BASE_URL:PORT/jira/rest/api/2/permissions"
Regards,
Earl
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.