[HN Gopher] How I Built LoginWithHN
___________________________________________________________________
How I Built LoginWithHN
Author : hardwaresofton
Score : 120 points
Date : 2022-02-22 13:02 UTC (9 hours ago)
(HTM) web link (vadosware.io)
(TXT) w3m dump (vadosware.io)
| mariusmg wrote:
| Does HN has OpenID Connect support to integrate from another
| website ?
| Aachen wrote:
| Apparently not or they'd have used that right?
| cactusbee wrote:
| Fun idea! Didn't work for me tho.
| DangitBobby wrote:
| Can you elaborate on how it didn't work for you?
| kaan_keskin wrote:
| I put the phrase in my profile but it couldn't complete the
| validation in a couple of minutes. Probably same issue.
| JimRyan wrote:
| Has anyone built something like this (A service which checks the
| account description to verify ownership) for PlayStation Network?
| I know that psnprofiles have this kind of system in place, but I
| couldn't find a public project.
| guessmyname wrote:
| PlayStation Network already does OAuth2. Here is an example of
| a website making use of it - https://accounts.klei.com/login
| capableweb wrote:
| It's a bit unclear what details you get as an application
| developer when using LoginWithHN. Is it just to verify that a
| user is also a user of HN? Or do I get the news.ycombinator.com
| token so I can build HN clients that are able to post comments as
| the user?
| hnlmorg wrote:
| This is just a 3rd party service (not affiliated with HN)
| checking peoples HN profiles (which are public) for a unique
| string that the 3rd party service asks said user to set. It's a
| bit like how custom domains names are added to (for example)
| GSuite email.
|
| As an application developer, you get no access to HN because
| the 3rd party service doesn't have any access to HN to begin
| with. It's all just a clever workaround to validate "ownership"
| of a HN profile.
| wyldfire wrote:
| > Not every HN user is a YC founder
|
| Not _every_ HN user? Oh wow. So, like, only 80% of us? I guess I
| assumed that the vast majority of us were not founders. How many
| of you are founders?
| ketzo wrote:
| I consider myself to be indefinitely pre-founder, naturally.
| mhh__ wrote:
| You may not be a founder, whereas I am a merely temporarily
| embarrassed founder, I'll have you know.
| Aachen wrote:
| How it logs me in via HN without having to submit my HN password
| to a party other than HN (the one thing I was interested in,
| buried somewhere in the middle of the post) is this good old
| hack:
|
| > Provide[s] a unique code or phrase to put in their HN profile
| forgotpwd16 wrote:
| Yeah, a simple yet effective technique. Had to join a Discord
| server and they're doing something similar for some other site.
| Aachen wrote:
| It's also how domain ownership is verified before issuing
| security certificates. It's used in a lot of places.
|
| The title speaks of being a "login with X" which made me
| expect something else than this manual step, like you could
| login to HN in a frame and somehow it queried your login
| status or so. Depending on the CORS headers, that could have
| been possible but then every site on the Internet can query
| the same, unless this person talked to HN owners. To me this
| is just the core interesting part of the story (but then I'm
| a security person who works with web security on a daily
| basis). The title isn't intentionally misleading, and it's
| still a "login with", just not how I was expecting it.
| capableweb wrote:
| > How it logs me in via HN without having to submit my HN
| password to a party other than HN
|
| The title is a bit misleading, it doesn't actually "log you
| into" anything, it just verifies you're the owner of a specific
| HN account, at least according to
| https://news.ycombinator.com/item?id=30428282
| hombre_fatal wrote:
| Though you could still implement login this way.
|
| You visit /login-with-hn, the server generates a code for
| your HN profile, you add it to your HN profile, and the
| server gives you a long-lasting sessionID (e.g. cookie).
|
| Where it wouldn't count as "logging in" for me is if you have
| to first create an account with some credentials and then
| later link it to HN.
| capableweb wrote:
| Yes, you can "login" as in "confirm this is the HN user
| they say they are", but not "Login as the HN user" as there
| is no actual connection to HN besides a token in the
| profile.
|
| When someone implements "Login with Google", you get some
| sort of access to the Google account, the minimum being the
| email. But this service gives you nothing more than the
| public view of a HN profile. If someone told me I could
| "Login with HN", I'd expect things like the ability to post
| comments/submissions via that account when authenticated,
| but that's not what's happening here.
| hombre_fatal wrote:
| Well, when I log in with Github/Google/Twitter, I don't
| necessarily need to confer any account access to the
| website and I almost never do, so I'm not sure that's the
| defining factor of 3rd party login.
|
| At that point, 3rd party login really is just "we'll
| contact their servers to authenticate you and then give
| you a session."
|
| One example would be StackOverflow which lets you log in
| with Google/Github/Facebook but doesn't ask for any
| permissions on those websites.
| yannikyeo wrote:
| Just curious what's the advantage of using Ory stack, which is
| more work that requires you to develop the front end, rather than
| with Keycloak or Authentik that you just customise the front end
| template?
| hardwaresofton wrote:
| The advantage of ORY was that it required this somewhat custom
| frontend (since it's not password based) -- I'm not sure how
| much easier that would have been with Keycloak (my guess is it
| would have been harder), and I haven't used Authentik before so
| I'm not sure.
|
| Keycloak is definitely more setup and a bit more clunky. I've
| never deployed Authentik though, I really need to kick the
| wheels on it and see how it works.
|
| BTW in the simple auth/login space there is also:
|
| - Keratin[0]
|
| - GoTrue[1] (and Supabase's improved version[2])
|
| - Authelia[3]
|
| [0]: https://keratin.github.io/authn-server/#/
|
| [1]: https://github.com/netlify/gotrue
|
| [2]: https://github.com/supabase/gotrue
|
| [3]: https://github.com/authelia/authelia
| adrianwaj wrote:
| Could you also setup an HN cryptocurrency (or token) and grant
| units according to karma and account age please (or whatever
| other factors you deem important)?
|
| - let's see what happens then to all the crypto skeptics around
| here. An about-face?
| ushakov wrote:
| that already exists
|
| https://badge.orangedao.xyz
| adrianwaj wrote:
| I don't like the look of that, but I like the name hacksweet,
| hoinz or hackoinz as names. For the first, each unit is a
| 'sweet.'
| WrtCdEvrydy wrote:
| Yeah, we need NFTs of your login so we can sell those.
| akselmo wrote:
| Add an ugly monkey on your profile information!
| andrewfromx wrote:
| Woah woah woah. Too far. Every monkey is beautiful.
| akselmo wrote:
| The one I see in the mirror every morning disagrees.
| dang wrote:
| Please don't toss flamebait into HN threads. It leads to
| repetitive, tedious flamewar, and you can make your substantive
| points without it.
|
| https://news.ycombinator.com/newsguidelines.html
| _Algernon_ wrote:
| Considering what moons did to the quality of discussion on
| various crypto subreddits, I think it is fair to say that this
| is a _really_ bad idea, no matter what side of the crypto
| debate you stand on. At least if you appreciate HN discussions.
| Aachen wrote:
| What's a moons? I'm out of the loop, apparently
| _Algernon_ wrote:
| A crypto currency distributed by accumulating karma on
| r/cryptocurrency. Essentially it encourages shitposting and
| karmawhoring.
| gavinray wrote:
| > this.ongoingPolls.set(hnUsername, displayToken);
|
| Instead of creating a timer + poll loop per user on your server,
| why not use one single scheduled job and an array of usernames?
|
| Seems like debugging +10,000 interval timers could get hairy
| hardwaresofton wrote:
| You're right, that would be way more efficient -- it actually
| wasn't a huge problem, so I never found the need to combine
| them.
|
| So far we've had 700+ people log in (probably more after this
| post hit front page, I need to check), and so far it hasn't
| been a huge issue.
| zeroxfe wrote:
| I sidestepped a whole bunch of user/password
| management/verification complexity by restricting my toy app
| (https://pitchy.ninja) to "login via email" where you get sent a
| code anytime you need to log in.
|
| I wasn't sure about how well it would work when I first launched
| it, but now, about a year and a half later, I'm really happy with
| it.
|
| The biggest advantages are: I'm not tied to an SSO provider, I
| don't have deal with password management/security/reset/etc., and
| I have a super simple UX (identical flows for signup and login.)
| mooreds wrote:
| This is a great option for UX. Here's a fun old post from 2008
| (from a former co-worker) on a similar topic:
| https://almaer.com/blog/its-just-my-email-password
|
| You do want to make sure you add enhanced security around
| changing an account's email address (make them log in again,
| for example). The analog is forcing people to re-enter their
| password when changing their password in a more typical
| username/password system.
| huhtenberg wrote:
| It'd be prudent to have an option of a backup email address, in
| case the primary one on file dies or becomes unavailable.
| errantmind wrote:
| This is only possible if you store client state, like the
| primary email address.
|
| I use the same approach to the above, where users
| authenticate with an email address. I don't store any client
| state on the server though which is nice for regulations like
| GDPR.
|
| I have 'logged in' users without storing a single piece of
| data about them! No tracking nor performance stats on the
| site either.
| adroitboss wrote:
| I do the exact same thing for all of my new applications. Magic
| Link Auth is 10x easier then trying to store passwords. The
| added benefit for the user is they don't have to remember any
| more passwords besides their email password. Which is already
| used as a source of truth.
| ivanhoe wrote:
| The two big issues with this approach is that emails can be
| significantly delayed sometimes, and/or can end up in the spam
| folder.
|
| If you can reliably avoid these two, you're golden.
| rexreed wrote:
| A good percentage of our outbound emails end up in Spam
| folders, Promotion inboxes, or heavily delayed. It might be
| simple to implement send a login link via email and convenient
| for those when it works, but when it doesn't, it doesn't. So
| the best is to have traditional passwords and an optional "send
| me a login link". If they get one of those two working, then
| great. But you still have to deal with password management /
| security / reset / etc. Nothing is trouble free.
| jeremyjh wrote:
| Don't you want to validate a new users email address before
| you activate their account anyway?
| rexreed wrote:
| When the email is not received in the customer inbox, you
| have a bit of a loop where the customer has a valid email
| but is not receiving the communication.
| dspillett wrote:
| Nice. I see potential problems, but nothing that would stop me
| using the idea for a personal project until it grew into
| something else (at which point I move to something else, and if
| it never gets to that point I've lost nothing but gained time
| I'd have spent implementing something else).
| TrueGeek wrote:
| I'm doing the same, but using Auth0 for the login-by-email. I
| don't think it'll really tie me to anything since it would be
| trivial to change to another service.
|
| What did you use to implement yours?
| zeroxfe wrote:
| I got an SMTP gateway from AWS: https://aws.amazon.com/ses/
| lopis wrote:
| My annoyance about this approach is that it forces me to open a
| cookie exception to your app, or to get a new magic link each
| time.
| dspillett wrote:
| That shouldn't be an issue unless you block session level
| same-server cookies, which is a bit OTT.
|
| Or it is implemented with longer lived cookies and you block
| everything that won't expire with your current session.
|
| (or you don't mean that you are blocking cookies but instead
| that the site is requesting you allow "strictly necessary
| cookies", in which case the site is being overly cautious, no
| regulation requires requesting consent for a strictly
| necessary stored value and a value tracking a login session
| fits into any reasonable definition of that)
|
| The concern I'd have with "login via email" implemented this
| way is that it could be faf to support if your sending mail
| server gets unexpectedly added to a blacklist somewhere so
| the messages stop getting through to a bunch of your users.
| That said, for a personal project I'd guess the risk is low
| if you are hosting on a reasonably good provider, don't have
| competitors who'd DoS you by making your service send out
| login tokens to a pile of random addresses. And even if it
| does become a problem it won't be an earth-shattering one for
| a toy project. I may have to try it in a future plaything.
| oarsinsync wrote:
| As someone who lives in private browsing mode only, and
| stores no history ever... yeah. This is a service I
| wouldn't use.
|
| Developer convenience over user experience, is great, until
| you realise your users are crazy.
| Groxx wrote:
| Why would email instead of user/pass/oauth require you to
| change your cookie settings?
| mtc39 wrote:
| FYI, in Firefox, hitting the back button does not take me back
| from your app.
| sleepychu wrote:
| Neat, interesting read :-)
|
| I gave loginwithhn a go, I'd recommend getting the user to type
| in the OTP. Checks their generation method is correct and makes
| sure they've managed to grab the secret before locking them out
| of future logins.
| hardwaresofton wrote:
| Great suggestion! This is not the first time it's been
| suggested either, I'm going to look into it!
___________________________________________________________________
(page generated 2022-02-22 23:01 UTC)