I wanted to embed live JIRA tickets inside an internal admin page. Cross-origin cookie isolation said no, and the embedded ticket rendered logged-out every time. The fix wasn’t to defeat the browser. It was to stop fighting it and let JIRA open where its cookies already live.

What I was building

I run an 880-ticket backlog with a small team, and I’d been building an internal triage surface inside our admin panel. The idea for ticket-shell was simple: an admin page that shows the current JIRA ticket inline, with Prev/Next buttons so I could walk a queue without leaving the page. JIRA holds the ticket data. My page holds the queue logic. The obvious move is to drop the JIRA ticket into an <iframe> and let it render.

That obvious move is exactly where you hit the wall.

The wall: cookies don’t flow into a cross-origin iframe

JIRA’s session lives in cookies set on JIRA’s own origin. Mine is a self-hosted instance on its own subdomain. My admin page lives on a different origin. When I load JIRA inside an iframe on my page, the browser treats that subframe as a cross-origin, third-party context and won’t carry JIRA’s session cookies into it. The frame makes its request unauthenticated, and JIRA does the only sensible thing it can: it serves the logged-out view.

So the embed worked: the iframe loaded. It just loaded a login screen instead of the ticket. Nothing errors out. The cookie failure is silent; the frame renders fine and is simply logged out. That is the entire point of the isolation. Same-site and third-party cookie rules exist precisely so that evil.example can’t embed yourbank.example in a hidden iframe and ride your logged-in session.

The page does have a 4-second watchdog for the other failure mode, an iframe that never loads at all because JIRA set X-Frame-Options or Content-Security-Policy: frame-ancestors to refuse embedding. When that fires it shows an “Iframe load failed” card pointing at the embedding headers first, then the cookie case. But the cookie problem is quieter than that. The frame loads, the watchdog never trips, and you just stare at a login screen.

Here’s the part the framing usually gets wrong: I own this JIRA. I could go change its X-Frame-Options in admin. What I can’t change is the cookie boundary. Even on an instance I control, there is no header I can set on my admin page that makes a browser carry a different origin’s session cookie into my frame. SameSite=None, partitioned cookies, the Storage Access API, document.domain games, none of them turn a separate-origin login session into an embeddable one for a passive iframe. This is not a bug to route around. It’s a security boundary working as designed.

The honest read of the situation: I was trying to share a logged-in session across an origin boundary the browser is built to keep separate. The browser won. It was always going to win.

The pivot: one reused popup instead of an iframe

When the session won’t flow into the frame, the answer is to stop putting JIRA in a frame at all. A top-level window navigated to JIRA is a first-party context. The cookies flow. You’re logged in, because it’s just JIRA in a normal browser window, the same as if you’d typed the URL.

So I shipped a popup mode for ticket-shell. The commit that added it touched the server page, the client JS, and the stylesheet. The shape:

  • A ?mode=popup query param and a View select in the top bar (Iframe / Popup), so I could flip between the inline-embed attempt and popup mode.
  • In popup mode, the area where the iframe used to live now shows a centered card: the current ticket key and an “Open in JIRA” button.
  • That button calls window.open to load the real JIRA ticket in a separate, top-level window. First-party context, session intact, ticket renders fully.

That alone solves the logged-out problem. But naive window.open introduces a second, more annoying problem, and that’s where the actual trick is.

The trick: a fixed window.open name

window.open(url) with no name, or with a unique name per click, spawns a brand new window every single time. Walk a queue of 30 tickets with Prev/Next and you’ve carpet-bombed your desktop with 30 JIRA windows. The queue walk becomes unusable: more time spent closing windows than reading tickets.

The second argument to window.open is the window name (the same target you’d put on an <a> tag), and it’s the whole fix:

// Spawns a new window on every navigation. Don't do this.
window.open(jiraUrl);


// Reuses the SAME window every time. Do this.
var POPUP_WINDOW_NAME = "jiraTicketWindow";
window.open(jiraUrl, POPUP_WINDOW_NAME, "noopener=no");

The noopener=no matters: the default noopener behavior severs the handle the browser uses to find a window by name, so leaving it on can break the reuse and spawn a fresh window anyway. Keep the opener relationship and the named lookup works.

When you pass a fixed name, the browser looks for an existing window with that name first. If one exists, it navigates that window to the new URL instead of opening another. So the first “Open in JIRA” pops a window; every subsequent Prev/Next navigation reuses it, swapping the ticket in place. N popups collapse to one reused popup. You get a stable JIRA window parked off to the side that always shows whatever ticket you’re currently on, and your admin page keeps the queue logic.

That’s the entire workaround. A query param, a toggle, an “Open in JIRA” button, and a hardcoded window name. It’s almost embarrassingly small next to the amount of time you can lose trying to coax cookies across the boundary.

Why this is the right shape, not a hack

It’s tempting to file the popup under “gave up and used a workaround.” The iframe embed was the hack. It was an attempt to borrow a session across an origin boundary that exists specifically to stop that. The popup isn’t defeating anything. It’s using the browser exactly as designed: first-party top-level navigation, real session, real cookies.

The fixed window name is the part worth stealing for other contexts. Any time you’re bouncing a user out to a third-party surface repeatedly (an external dashboard, a doc viewer, a payment provider, a separate admin), a single named window keeps the experience coherent instead of littering. It’s the difference between “open the thing” and “open the thing, again, in a new window, forever.”

If you’re wiring this into your own admin tool, the check is simple. Pick one fixed window name for the popup, keep noopener=no, and then walk a queue: open a ticket, hit Next a handful of times, and confirm your taskbar still shows exactly one JIRA window, not a new one per click. If a second window ever shows up, the name got dropped or changed somewhere in that click path, and that’s the bug to chase.