This shouldn't be possible as the server-to-server request to Facebook to exchange the Authorization Code for an Access Token requires the client_id and client_secret to be provided. Facebook should (though I haven't actually confirmed this) verify that the code was issued to the given client_id. If the code was issued for client 123, when client 456 tries to exchange it for an Access Token Facebook should throw an error.
I think they've always done this redirect. Release artifacts are uploaded to S3 and then their Rails app generates a presigned S3 URL that gives short-term access. This is because the artifacts could belong to a private repo, so access control is required.
I’m building a side project that has an enterprise customer, and the Enterprise Ready website was a good intro to the concepts that enterprises value: https://www.enterpriseready.io
From my (limited) experience, one thing that enterprises love is asking you to fill out a 30 page security questionnaire. They take an age to complete so be aware of this if you’re thinking of going down the enterprise-sales path. I think it’s one of the big reasons that “contact us for pricing” exists for very large customers.
The article has quite a nice introduction to deep learning concepts, but the headline claim of building an ID card reader from scratch is little more than "use our API".
If you received a HTTP 502 then DNS must've already resolved. Browsers typically will do a DNS lookup, and then try establishing a TCP connection to one of the returned hosts. Its only if it can't establish a TCP connection to a host will it (sometimes) try another host from the DNS response.
Exposing whether an account exists is a risk, but the alternative is also a hard problem to solve. Sign In screens could throw a generic error that doesn’t reveal whether it was the email address or password that was incorrect, but what about registration flows?
If users can sign up and register to your system, it’s harder to offer a slick user flow without revealing that an account already exists. One way to achieve this is to only capture the user’s email address, send them an email, and they complete the rest of the sign up process as a second stage. A user who already has an account gets sent an email stating that an account already exists.
As a business I assume they’ve decided that the risk of exposing whether an account exists was worth it in exchange for a better user experience.
This frontend presents them nicely: https://trains.jo-m.ch