It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Access JIRA API on locally hosted

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

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

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

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

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

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

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira

Demo Den Ep. 7: New Jira Cloud Reports

Learn how to use two new reports for next-gen projects in Jira Cloud:  Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...

308 views 1 3
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you