TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

A bizarre “403 Forbidden” bug-hunting adventure

137 点作者 joshsharp超过 7 年前

10 条评论

luketheobscure超过 7 年前
&quot;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.&quot;<p>I imagine it honors the &quot;expires&quot; property of cookies, it just probably wasn&#x27;t set. Also there&#x27;s an &quot;ephemeralSessionConfiguration&quot; you can use if you don&#x27;t want to store the cookies. I enjoyed the article, up until the author blamed the framework for their own ignorance.
评论 #15345579 未加载
评论 #15346206 未加载
js2超过 7 年前
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>
udioron超过 7 年前
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&#x2F;cookie authentication.
评论 #15345670 未加载
评论 #15345675 未加载
Grollicus超过 7 年前
Despite using Functions he doesn&#x27;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.
exikyut超过 7 年前
This is both awesome and depressing.<p>But it gave me a really interesting idea: a service&#x2F;network&#x2F;community&#x2F;forum&#x2F;etc for people to gather and discuss Really Confusing Bugs™ that they&#x27;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&#x27;ve been staring at for days&#x2F;weeks and nothing&#x27;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&#x27;d have to check a box to make the discussion private, and even after that you&#x27;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&#x27;ve just described a weird kind of paid StackOverflow. I am very curious why SE hasn&#x27;t pursued such an idea. As in, I am 1000% confident they&#x27;ve had this conversation <i>at least</i> once, and I&#x27;d really love to hear what the opinions were.
评论 #15345521 未加载
评论 #15345508 未加载
评论 #15345454 未加载
catshirt超过 7 年前
when you have a bizarre request issue... find a working request, find the failing request, compare the headers... problem solved.
评论 #15348895 未加载
stanleydrew超过 7 年前
Not sure about the &quot;fix&quot;, since now users can&#x27;t persist a logged in browser session?<p>If you aren&#x27;t using cookies for API auth, is there not some way to configure your server framework to just ignore them if received?
评论 #15345574 未加载
CodeWriter23超过 7 年前
Just popped in to say Wireshark would have made short work of this bug.
foota超过 7 年前
Are they using a header or s.t. for their authorization in app, then?
评论 #15345510 未加载
oretoz超过 7 年前
Za