How to Discover Rogue/Accidentally created Atlassian Sites yourself!

[#1]

So there's a great new suggestion here:

CLOUD-12089 - Additional cancellation reasons on "Cancel your subscription" page

Where I provided my data:

We migrated to Cloud in May 2024. This required people to learn a new URL for Jira and Confluence. 

Unfortunately this also means that people forgot that new URL, and we have since had 41 SITES created by mistake.

That's 41 sites for which I've had to: 

• Notify the user who created the site, and confirm it was a mistake (100% have been mistakes).
• Make myself admin of the site.
• Request cancellation of the site.
• Open a ticket requesting expedited cancellation and deletion of the site so I do not have to wait for 30 days or whatever the minimum is these days.
• Confirm in the ticket that I really really want to delete the sites and DO NOT want to rename or swap them with other sites.
• Wait a minimum of 14 days for the site to be deleted.
• Remember to go back on site deletion day, confirm deletion, and then delete the organization.

I have an Excel sheet tracking all of this

What's interesting about those 41 sites, is that Atlassian's notifications for Discovered products (which is definitely not the same as "Jira Product Discovery") only are only sent once every 24 hours, and I'm impatient. 

So you can certainly bookmark and regularly check the Discovered products page for the Organization where you have verified your domain for "managed" accounts. (I put managed in quotes because if your users can still create rogue sites, are they really managed?). That URL will look like this:

https://admin.atlassian.com/o/YOUR_ORG_ID/discovered-products

And it's this page:

But manually checking is so.... manual.

How about we automate this?

Well, the bad news is, this is VERY HACKY. But the good news is, who cares, it's fun!

So, there is an API endpoint to obtain the list from the page above. And in fact it contains more info than is displayed including: the timestamp when each site was created, and a mysterious flag, "isVortexed" (oooooh).

BUT, you cannot use API tokens or Organizational API keys to authenticate to this endpoint. You must use the cookies for admin.atlassian.com. This is super-janky, and will probably need to be updated every month. (Also you don't need ALL of the cookies, but I'm frankly too lazy to isolate just the ones you really need.)

Pre-requisites

• curl = command-line web client maybe already installed in your computer's terminal/shell
• jq = a lightweight and flexible command-line JSON processor - this lets us convert the data from the API into something easily readble)
• EditThisCookie = Chrome extension that lets you easily copy cookies for a particular site.

Getting the cookies (nom nom)

So because the API endpoint for Discovered Products is unofficial, we can only get to it when we're logged into Atlassian Guard. But you can't "log in" with curl. So we're doing the next best thing. Taking the cookies that say we're logged in in Chrome, and pasting those into a file that curl will read.

(IMPORTANT SECURITY NOTE: you do not want to store this cookies.txt file on a shared computer. I am running this script on my computer which already has these cookies, so nobody else can access the cookies.txt file, but if you did store this file somewhere and somebody got access to it, they can use it to log into your Atlassian Guard WITHOUT A PASSWORD. SO do "guard" it carefully.)

Anyways, under Options for EditThisCookie, you want to choose this preferred export format: "Netscape HTTP Cookie File"

You then want to go back to admin.atlassian.com and if you're logged in, click on the cute cookie icon in your Chrome toolbar/extensions to see all the cookies for admin.atlassian.com and atlassian.com. You'll then click on the "Export" icon to copy those cookies to your clipboard.

Then you just need to open your favorite text editor and paste those cookies into a file and save it. (I chose the filename cookies.txt)

AND NOW... hopefully, we can run the script:

Here's the script, which I have only tested on a Mac running MacOS 14.6.1:

curl -s -b cookies.txt https://admin.atlassian.com/gateway/api/admin/v1/orgs/YOUR_ORG_ID/products/unmanaged | jq . > `date -I`-discovered.json

jq -r '[.data[].attributes.product | { "siteUrl": .siteUrl, "creationDate": .creationDate} ] | sort_by(.creationDate) | [first|keys] + map ([.[]])|.[] | @csv ' `date -I`-discovered.json

Here's how it works:

Part one:

curl

-s	Silent or quiet mode. Do not show progress meter or error messages. Makes Curl mute.
-b cookies.txt	Pass cookies from the cookies.txt file

jq . (this formats the discovered sites into a more easily readable file)

`date -I`-discovered.json (this is the built-in date command to generate today's date in the format 2024-10-28, prepending that to -discovered.json, to give you a filename of 2024-10-28-discovered.json

Part two:

jq (I'm going to try to break this down for you)

-r	this parses input as a string. it uh, takes care of double-quote issues.
[.data[].attributes.product	so data is an array of sites. We want to get the product attributes for each site.
{"siteUrl": .siteUrl, "creationDate": .creationDate} ]	this is getting the siteUrl and creationDate for each site. It's storing each pair as a JSON object (those are the {braces}, and putting that in an array (that's the outer [brackets])
| sort_by(.creationDate)	the whole reason for putting this into an array is to let me sort by creationDate
| [first|keys] + map (.[]])|.[] | @csv	ok, so this is some jq voodoo I found that basically takes an array of JSON objects, and converts it to a CSV with headers.

FINALLY

ANYWAYS, what you should end up with is a file saved in your directory named 2024-10-28-discovered.json. If you view the file, it should be fairly understandable, something like this:

{
  "data": [
    {
      "id": "ari:cloud:jira-software::site/SITE_ID",
      "type": "unmanagedProducts",
      "attributes": {
        "product": {
          "id": "ari:cloud:jira-software::site/SITE_ID",
          "key": "jira-software",
          "siteUrl": "ROGUEONE.atlassian.net",
          "creationDate": "2024-07-04T00:43:32Z",
          "createdBy": "GUILTYPARTY@YOURDOMAIN.com",
          "status": "Active",
          "statusReason": null,
          "lastActiveTimestamp": "2024-07-04T01:56:45.070356986Z",
          "orgId": "ORG_ID",
          "isVortexed": true
        },
        "usageCount": 36
      }

...

So that's neat, and you now have a historical record of all the discovered sites.

But what my script also does is parse that file to JUST show you the siteUrls and creationDates, with the newest ones at the bottom, so you should get output like:

% ./discoverjson.cmd
"creationDate","siteUrl"
"ROGUEONE.atlassian.net","2024-07-04T00:43:32Z"
"ROGUETWO.atlassian.net","2024-07-15T08:23:56Z"
...

And so, hopefully you get an up-to-date view of all of the sites that any of your "managed" users may have created.

But really, it would be nice if Atlassian just fixed the problem.

[Darryl Lee]

I have another suggestion I will be adding to CLOUD-12089.

Since it's highly unlikely Atlassian is going to add a new Cancellation reason that would acknowledge their broken login workflow that causes accidental site creations, what if we all agreed upon a hashtag that Atlassian could easily search on?

#shadowit ?

#accidentalit ?

Hm. I kind of like how that sounds like "accidentally" which is how all of my users created their sites. :-{

[Kieren _SmolSoftware_]

Nice write up @Darryl Lee. 

FYI, 'isVortexed' refers to whether the site is on the new user management experience (True) or not (False). Vortex was the project name for creating the new user management experience.

-Kieren
Co-Founder @ Admin Automations | Ex-Atlassian

[Darryl Lee]

Ah thanks @Kieren _SmolSoftware_ - yeah, now that I think about it Vortex does sound vaguely familiar. I think somebody I chatted with in Barcelona may have mentioned it.

Ah, the new user management experience introduced in 2021 that our Org still doesn't have access to. :-}

(Too many users? Multiple product sites, ... I can't remember the latest hold-up.)

Well, oof, I'm just hoping that it doesn't include the improved billing experience because I don't look forward to waiting 60 DAYS to delete accidentally created Orgs. :-/

[Matt Doar (Adaptavist)]

Excellent description of the process, thanks

[Darryl Lee]