Hacker Newsnew | past | comments | ask | show | jobs | submit | BryanGiese's commentslogin

Here's the discussion summary and video link. https://fusionauth.io/blog/2019/12/19/open-office-hours-19-1...


The AppleTV remote is the WORST. In general, the worst remote ever made.


Interesting perspective and I can see some of the intent here, but it takes an odd slant to the issue. There are a few failures in logic here (random number becoming PII, only tracking on one browser, laws protecting you from getting robbed) that detract from the goal of GDPR which is to outline the user's digital rights, not define how data can be collected. GDPR does not define the technological methods because those will always be evolving, much like our understanding and expectations of data privacy will evolve. I agree that users need to educate themselves on how to protect their own data, but there is a ton of technology that they either aren't aware is being used, or simply don't understand. GDPR isn't perfect but it will help in the long run. Here is a summary of some of the details and how it will impact what developers need do as they architect software. Some companies will take it seriously, others won't. Then consumers may decide who to do business with. https://fusionauth.io/blog/2019/01/29/white-paper-developers...


WHYYYY are they so far behind???


100 million users? Does anyone need to have that capability?


I think the point is handling peak loads and knowing you can get all your users (whatever that number might be) back online quickly. To quote the article "what happens if Call of Duty goes offline for maintenance and then six million users try to log back in at the same time"?


Good point. Skimmed that. But how often does that really happen? Don't sites and apps just handle that? Isn't that an IT job?


My friends argue about the best strategies for this. Will send to them to stoke the fires.


Many prevailing strategies simply persist the JWT, this works, but is more difficult to scale and sort breaks the portability idea in my opinion.

Once you persist it - you might as well be using a session. I suppose it depends on your scale - maybe with just a couple of thousand users it would work ok to store every JWT issued for their lifespan.


Are people really running into such terrible scaling issues with their session database that the solution is to ditch it and use an entirely different authentication strategy? It's not like we haven't been scaling databases for decades!

I agree that persisting the JWT means you may as well be using a session, but my takeaway from that is that you should just use a session, not come up with more weird workarounds to justify JWTs.


Randall Degges has a blog post on this. It's pretty good actually: https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-...


I'd say it is always good to have options. If sessions work, that is a safe option and easy to manage state.

If at scale this option doesn't work - or at least not as well as you'd like, additional strategies are good to know.

If you plan for Pokemon Go, or Fornite scale, decoupling may be beneficial. Admittedly this is a small percentage of all of the use cases.


We're working on that at FusionAuth.io too. ;)


Are you a seagull from Finding Nemo? MINE


Nice. Lightweight and in Python. FusionAuth has something similar that is Python3 compatible with more features. Just have to balance out what you need.


Python 3


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: