Apache web servers have an "easy" way to password protect files and directories. It involves using an
.htaccess file and an
.htpasswd file. After that's set up, if a browser tries to access a file protected in that way, it'll pop up a login/password modal:
That's true even if the page requesting it is inside an iframe. Meaning that this can happen inside CodePen. Here's a screenshot of Firefox requiring auth on a JPG asset:
(It's not isolated to Apache servers. Any server can do this. It's called HTTP Basic Authentication. It's just particularly common to set up in that way.)
There is nothing terribly wrong about that feature of servers and browsers. Except that there is this whole concept of sandboxed iframes, the point of which is security and annoyance-blocking. For example, if you do:
You're saying "I want this iframe pretty locked down. No scripts, no forms... The only thing I'm explicitly allowing is popups like
window.open()". If you don't put
allow-popups as a value in the
sandbox attribute, then popups will be blocked. It's wonderfully useful, particularly in a place like CodePen where we use iframes heavily to display people's work, but want to avoid anything dangerous or obnoxious.
.htpasswd popup though, that has long snuck by as being something
sandbox was unconcerned with. You couldn't allow it or disallow it, iframe or not. But in some fairly recent release of Chrome, it's now preventing these popups almost entirely. If you peak in the network area of DevTools, you'll see the requests 401 (error):
It's not our iframe that's causing this, as even Debug View (no iframe) 401's the request in Chrome. The only way to get the auth popup is to hit the URL directly in the browser.
The auto-blocking seems a bit heavy-handed to me, but I prefer it to seeing these dang popups all the time when just boinking around CodePen looking at stuff.
In a perfect world,
allow-popups (or some new value) would allow these auth popups to come up through an iframe, and not being there would block the requests.