You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
As I understand it, the only authentication option available that isn't based on a username/password is Oauth. Does it make sense to set this up to be used in a script environment where asynchronous callbacks can't be listened to?
If no, are there other authentication options that are not based on username/password?
I'm struggling with this problem too - I don't want to bake in usernames and passwords to scripts.
I have looked up the Atlassian OAuth examples, stored in it's hg (??mecurial??) respository but they no longer work on my client due to RSA SHA1 being deprecated and the scripts now throwing errors.
But that's nothing compared to having to set up application links in Jira - which fails at asking for the application URL. There isn't one, obviously, as my scripts are CLI client side actions. They could happen at any time, driven by our continuous integration factories - and I'm not likley to be on hand to log in to a browser and grant permission. How does anyone set up an OAuth app link?
So how do we arrange a revokable permission, like adding a public key to an "allowed" list and authenticating against that, like passwordless ssh?
Kerberos is not based on username and password.
-Lars
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.