Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Automation for Jira API Authentication - CLOUD

Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Nov 28, 2021


Starting a thread to hear what other Jira Admins/Users are doing to tackle this...

Keen to hear how you protect the base64 encoded authentication inside your A4J rules?

Occurred to me that maybe an attribute insight an Insight Object inside a locked down schema could potentially work? I just worry about project admin's accessing the rule and using the auth inside the web request. 

Aware it could be set as a global rule to prevent project admin's accessing but still not really great from a security perspective

1 comment

Mykenna Cepek
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Nov 30, 2021

Interesting question! Sounds like a good Product Suggestion to offer to Atlassian.

Thinking this through, I don't see a way to truly lock this down with Automation as provided today. If the rule is able to look up the value and use it, then it's either exposed or easy to expose.

As you say, a project admin having access to a (project-specific) rule means the content of that rule (and the rule itself) is vulnerable. For example, a project admin could just add an "Audit Log" (or other) action to expose the value, no matter how tricky the rule was in retrieving/decoding/etc that value.

This suggests that the rule itself needs to be secure, leading back to your global rule approach (which simply reduces the scope of admins with access). However, this approach isn't a slam dunk, because:

  • A rule set to "Multiple projects" but with only one project listed will revert to being set to a "Single project" (once you sneak past the first warning it gives).
  • Multiple project rules can cause automation limits to be exceeded (for non-Enterprise level plans).

Interested to see if anyone else has ideas on this!


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events