

I am guessing they don’t have an IP protection for liquid/dust.
The product page’s specification’s section lists it as having “IP66 certification: Splash proof and dust resistant”


I am guessing they don’t have an IP protection for liquid/dust.
The product page’s specification’s section lists it as having “IP66 certification: Splash proof and dust resistant”


Can you walk into a store in The Netherlands, pay cash, and walk out with a anonymously-purchased SHIFT phone?


looks like they’re collaborating by giving some of their profits upstream, and creating feature requests


That’s bad.
OAuth supports several types of flows. If I’m not mistaken (I’ve learned a bit more about OAuth since yesterday) you’re describing the Authorization Code Flow – as documented in RFC 6749 (The OAuth 2.0 Authorization Framework), Section 4.1 (Authorization Code Grant):
That RFC defines many other types of flows that do not require sharing the access keys with a third party, such as the Client Credentials Flow, as documented in RFC 6749 Section 4.4 (Client Credentials Grant):
The only reason you’d want to use the Authorization Code Flow is if the third party needs your access token for some reason, or if you want to hide the access key from the user agent.
The problem here is that Stripe is using the wrong flow (the third party doesn’t need the access token, as they claim they never save it anyway). And if keyCloak only supports that one flow, that’s would be a problem too (in this case).


Stripe Connect does not support Client Credentials flow.
Can you please tell me what is the name of the “flow” that Stripe Connect is using here?


I figured out the root technical cause. It’s because Stripe doesn’t allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that’s hard-coded into the app.
For security purposes, Stripe redirects a user only to a predefined URI.
That’s why Stripe forces you to expose your access tokens to the developer’s servers.
I’d still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer’s servers.


It’s called the Client Credentials flow (RFC 6749, Section 4.4).
Finally someone directs me to the actual RFC. Except that section is titled “Client Credentials Grant”
Why do I see this sometimes called a “Grant” and sometimes called a “Flow”?
What’s the definition and difference of each?
Oh wow, there’s no aux jack!?! Thanks for pointing that out. That kills this for me.