Safari not prompting for basic authentication Our website provides hyperlinks to third-party software which requests basic authentication.  Previously a user would click the link, they would be taken to the new URL, and an authentication prompt would be shown.  On the recent update Safari no longer prompts for authentication, and users are given a 401 Unauthorised error immediately.  If you reload the page, it will prompt.  Pasting the URL directly into the address bar works correctly.

This is not due to caching or cookies.  I can confirm it was working fine in macOS Safari 11.0.1 and is broken in 11.0.2.  Chrome does not exhibit this behaviour.  I have also confirmed the same issue affecting iOS Safari, but I have not isolated versions.

Loading a test page from my local HDD does not give the same problem, but when hosted via IIS (on our web server or on my development machine) it fails every time.  An example page is hosted here:

https://go.itelescope.net/auth_test.html

It links to a test authentication server here (this test server does not display a 401 error, but it still should show the authentication dialog):

http://httpbin.org/basic-auth/user/passwd

Has anyone seen this before, or found a solution?  I'm also reporting this to Apple but since I'm not an Apple Developer I expect it to get lost in the noise.

Update

A user on the Apple Communities forum post I made has said this is a design decision by Apple, but I have yet to get any more information (or confirmation) on this.  However the evidence seems to corroborate his information: the error only occurs when linking from an HTTPS site to an HTTP site.

StackExchange is hosted securely, so linking to the secure site works:
https://httpbin.org/basic-auth/user/passwd
While the non-secure does not:
http://httpbin.org/basic-auth/user/passwd

I have also reported this via the Apple Bug Reporter tool.  My first report has mysteriously disappeared.  I have re-logged, but have also heard many accounts of bug reports never being responded to.  If anyone here has a reliable reference that this is an intentional change, that would be great.  Otherwise I still consider it a bug.
Well since I can't find a definitive public answer, I'll do the next best thing.  This is the response I got on a private bug report through Apple:


  This behavior is expected. Following the fix per another bug. We do not prompt for credentials whenever navigating to an insecure web page that requires authentication from a secure web page. Moreover, we do not prompt for credentials when loading an insecure subresource (say, an image) that requires authentication or a secure subresource that requires authentication through an insecure redirect on a secure web page. The motivation for these restrictions is to prevent phishing attacks by a networking attacker who could have replaced the contents of the insecure resource HTTP response with a secure redirect to their own server that prompts for credentials. Although the authentication prompt shows the URL being accessed, a person may not read the prompt closely or, more likely, an attacker can purchase a domain name that could lull a person into falsely believing that the URL is legitimate so that the person submits their credentials to the attacker.


I'm still looking for a public statement from Apple that can be linked to.  If someone can provide that I will mark that as the accepted answer.

UPDATE

Someone with authority at Apple got in touch with me about this.  They finally linked me to the official release document showing the changed behaviour: 


  Changed to only allow non-mixed content protected sub-resources to ask for credentials.
  https://webkit.org/blog/8035/release-notes-for-safari-technology-preview-44/
  https://developer.apple.com/safari/technology-preview/release-notes/#r44


We worked with Apple to address the broken user experience caused by this security fix. Apple listened to our feedback and fixed the credentials dialog for links from an HTTPS resource to an HTTP hosted resource. It works correctly now in Safari on Mojave onwards.