"NSURLSession oh so helpfully auto-fucking-matically decided I would probably—no, definitely—want to send those cookies in every single request my app did after that. Forever and always."<p>I imagine it honors the "expires" property of cookies, it just probably wasn't set. Also there's an "ephemeralSessionConfiguration" you can use if you don't want to store the cookies. I enjoyed the article, up until the author blamed the framework for their own ignorance.
Oh hey, I know this. From a commit message earlier this year for an SDK I own:<p><i>SDKSender: switch to ephemeral NSURLSession and disable cookie storage<p>Switch to a private (ephemeral) session independent of the app and
disables cookies. The SDK otherwise shares the cookie storage with the
app, which is not desired. This was causing the SDK to send the
$dayjob tracking cookie (and others) to $dayjob API endpoint.</i>
Another fix is to disable CSRF checks for all API calls which should not be served by a browser (assuming they use a different auth mechanism which does not involve cookies!). This makes sense since CSRF is a layer that relates to attacks involving browsers/cookie authentication.
Despite using Functions he doesn't really understand and yada yada i think this is a good reason to have a dedicated api endpoint and not mix it with domains where the normal web access happens.
This is both awesome and depressing.<p>But it gave me a really interesting idea: a service/network/community/forum/etc for people to gather and discuss Really Confusing Bugs™ that they're trying to figure out. Not necessarily (?) for contemporary end users (maybe highly technical end users).<p>This could actually be a really cool concept. Somewhere squarely between HackerOne and StackOverflow - not for exploits, and not for simple(r) stuff, but specifically for complicated and confusing bugs you've been staring at for days/weeks and nothing's making any sense.<p>I can see a subscription model working for this, even - subscriptions would work both to allow people to provide extended assistance, and also because a contract makes NDAs easier.<p>Hmm. Thinking about how the subscription model would work... you sign up, configure billing, that then allows you to request extended assistance.<p>- One way that could work is that people offer you help in return for thanks, which would work like a configurable upvote; higher quality answers attract more rewards. Maybe anyone can reward answers (via the credit in their account) after the fact?<p>- Another way would be setting a minimum or exact reward amount up front to attract more help.<p>Regardless of how it worked, the site would have all discussion be public and open by default; you'd have to check a box to make the discussion private, and even after that you'd have the ability to go through and selectively un-redact parts of the conversations so everyone could be helped.<p>And anyone could sign up and offer answers instantly, and the rewards credited to their account could be cashed out at any time. That would attract new users.<p>I realize I've just described a weird kind of paid StackOverflow. I am very curious why SE hasn't pursued such an idea. As in, I am 1000% confident they've had this conversation <i>at least</i> once, and I'd really love to hear what the opinions were.
Not sure about the "fix", since now users can't persist a logged in browser session?<p>If you aren't using cookies for API auth, is there not some way to configure your server framework to just ignore them if received?