Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Access JIRA API on locally hosted

ACBSun October 13, 2019

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.

2 answers

0 votes
ACBSun October 15, 2019

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.

Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 16, 2019

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

ACBSun October 16, 2019

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

Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 16, 2019

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

ACBSun October 16, 2019

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. 😞

0 votes
Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 14, 2019

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

Suggest an answer

Log in or Sign up to answer