This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-04-09
Channels
- # aleph (1)
- # asami (5)
- # babashka (4)
- # beginners (8)
- # biff (19)
- # calva (2)
- # cider (14)
- # clojure (17)
- # clojure-dev (3)
- # clojure-europe (3)
- # clojurescript (2)
- # community-development (9)
- # conjure (1)
- # core-typed (2)
- # datomic (6)
- # emacs (20)
- # gratitude (1)
- # helix (5)
- # kaocha (4)
- # nbb (1)
- # releases (3)
- # testing (17)
Hello hello, Great news about your progress on yakread :) I would like to use biff to build the backend for a mobile app and I have a couple questions about the default authentication plugin. • Is it possible to make authentication work smoothly with the routes for sending and verifying the 6 digit code? • Would a web view be required to make this work or would plain usage of the routes be enough?
hm, the main issue is that the default auth plugin authenticates users by updating their session. for a mobile app I'm assuming you'd want to have the route return a token instead. so for that you'd need to either modify the auth plugin/write a different one from scratch/just use firebase auth or similar. as for the second question--the only snag is that you have to submit a recaptcha token to the routes. I don't know if recaptcha has a native app version (I've never looked)
Ah I see, thanks for the info! I see that biff does have support for encrypting and decrypting JWTs. Would it be a big lift if I were to modify the plugin to create and send a JWT back from the verify-code route? Then on the inbound instead of checking for an active session it would verify the JWT? Or would that be more work than implementing Firebase auth?
I suppose there’s also the issue of refreshing tokens and all that, which probably tips the scale.
That should get the job done, and it shouldn't be that much work--just what you've described basically. And yes, the refreshing stuff is where it gets more complicated 🙂
which is what firebase auth would handle for you
technically if you just had one "regular" token (instead of access tokens & refresh tokens), and set the expiration to 60 days or whatever, and have the user log in again when it expires, then it seems like that would have equivalent security to standard website session authentication... but I haven't done any research on implementing token-based auth, so idk
every time I work on authentication I end up spending hours poring over web pages on owasp etc ha ha
yeah... if I were doing auth for a mobile app I'd probably just use firebase auth (actually I have done that before, back when I was working on an app). it's pretty straightforward to write middleware to parse the incoming token
Yeah, I have worked with parsing tokens before on an app that was using Auth0. I haven’t wired up the integration with the auth provider before though.
If I started targeting the mobile app use-case for Biff, then I'd probably take the time to implement token stuff without using firebase auth, since I feel like that's the kind of thing that a framework should provide. But just for a specific app, eh
the integration for firebase auth is pretty plug-n-play, especially if you use their off-the-shelf UI (at the cost of every programmer who uses your app thinking "I see they're using firebase auth")
I'm sure auth0 would also be fine, I just haven't used it myself
Alright, thanks a lot. This will help me plan and estimate this project better. I’m looking forward to using biff, it seems like a no-brainer to me, especially to have it baked right in with XT which I’ve been wanting to try for some time now.
Sure thing--hope the project goes well!
definitely let me know if you run into any snags with biff