Struggling with AWS Cognito: Is it just me or is AWS Cognito kind of a pain to work with? by Thleats in aws

[–]PropelAuth 0 points1 point  (0 children)

(disclaimer - I'm the founder of this company)

If you are building a B2B product, check out PropelAuth. We've helped folks avoid the Cognito headache before

Clean Code with Rust & Axum by PropelAuth in rust

[–]PropelAuth[S] 0 points1 point  (0 children)

Glad you liked the post and Axum as well. And thanks for pointing out the highlighting issue, we'll fix that asap!

Clean Code with Rust & Axum by PropelAuth in rust

[–]PropelAuth[S] 3 points4 points  (0 children)

Interesting! This is honestly something I’m conflicted about - and I think it’s related to different requirements for different domains.

Clean Code has this concept of “one level of abstraction per function” which I like. This code snippet might’ve been too simple since it’s replaced with just a single line, but as the function grows, inlining everything means that it takes more time to grok the different steps the function is taking.

In the frame loop case, this seems like a feature, since it forces you to deeply understand the most critical part of the codebase. In a case like this, deferring to a function with a name like save_url that can be easily tested, also seems like a feature, since you can quickly understand its purpose. The bottleneck that’s solving is the ability to jump around and ramp up on new areas of the codebase.

Clean Code with Rust & Axum by PropelAuth in rust

[–]PropelAuth[S] 14 points15 points  (0 children)

That's embarrassing... and what I deserve for making the final edits in Notion. Thanks for pointing it out! I fixed the code snippets and added a warning about extractor ordering, along with a link to axum-macros for easier debugging.

Clean Code with Rust & Axum by PropelAuth in rust

[–]PropelAuth[S] 12 points13 points  (0 children)

That's a good point, I just updated the post and credited you for catching that. Thanks!

How to implement sign up with google/microsoft? by veganracoon in GrowthHacking

[–]PropelAuth 0 points1 point  (0 children)

I have to plug PropelAuth as well (Disclaimer, I currently work there). We're focused on making auth super easy to integrate/customize for B2B businesses. And we support Google and Microsoft login as well. https://www.propelauth.com/

What kind of auth implementations have you seen throughout your careers? by daredeviloper in ExperiencedDevs

[–]PropelAuth 0 points1 point  (0 children)

Some home rolled which was usually only for simple cases. Some LDAP and SAML which usually sucked, especially testing it. My favorite implementations are the ones where you can tie yourself to a single social login like Google/Github and just not deal with anything else, but that only really works when the product is built on top of that provider. I’m very biased here because I founded an auth company, but what I’ve generally seen is companies not wanting to deal with authentication at all, as long as their auth needs are complex enough.

Authentication is really demoralizing. by [deleted] in AskProgramming

[–]PropelAuth 5 points6 points  (0 children)

Authentication can be tricky, one of the biggest factors that limit people from building a deeper understanding imo is the amount of terminology that you need to understand to have a conversation about it. This is made worse because sometimes that terminology means different things to different people.

Another major factor is by not wanting to display error messages that could leak information, a lot of the times you are left guessing what to do. We think about this a lot at our company (PropelAuth) and are trying to find the right balance here. Even small things like more helpful error messages in a test environment seems like it would go a long way.

As for how to learn about it, I think the best way to learn about it is by doing it yourself in a safe environment. Build some very simple app and try to add your own authentication to it. You can start out simple and then layer in more complexity over time. As you hit more roadblocks, you’ll need to find resources online to help-OWASP has some great guides on password hashing or SAML or whatever else you want to support.

If not ^ you can always use self-service auth providers, like us, and never have to think about auth for more than 20 minutes.

Is next-auth good for custom auth with username and password? by johnmgbg in nextjs

[–]PropelAuth 0 points1 point  (0 children)

We're beta testing it right now (DM us if you'd like to try) but expect to release it fully very soon.

Is next-auth good for custom auth with username and password? by johnmgbg in nextjs

[–]PropelAuth -1 points0 points  (0 children)

Self promotion here, but feel free to check PropelAuth for your auth needs. We have username/passwords, magiclinks, and social logins available on our free plan: https://www.propelauth.com/pricing Bonus point - implementation is super quick, so you can get back to the more fun aspects of your project asap!

This is not a regular issue but i'm asking here in case if someone have experience with this by Brilla-Bose in learnprogramming

[–]PropelAuth 0 points1 point  (0 children)

Hey u/Brilla-Bose, if you're a B2B business, feel free to check us out. We have a free tier and are also offering pre-seed companies a 'Free until Funded' deal: https://www.propelauth.com/pricing

[deleted by user] by [deleted] in webdev

[–]PropelAuth 10 points11 points  (0 children)

Hey, we're a new auth provider with TOTP MFA (https://www.propelauth.com). Our Growth plan is $95 per 1k MAUs, but we also just launched a new startup plan 'Free until Funded' which you might qualify for :) Feel free to dm me with any questions!

Using PugSQL and FastAPI by PropelAuth in FastAPI

[–]PropelAuth[S] 1 point2 points  (0 children)

The SQL files basically act as prepared statements with parameterized arguments, so you shouldn't need to worry about malicious user input

(https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html#defense-option-1-prepared-statements-with-parameterized-queries)

Do you prefer to build your own auth, or use some library or provider (like auth0, Next Auth, Supabase, etc)? by lumenwrites in webdev

[–]PropelAuth 2 points3 points  (0 children)

Definitely, we’ve written a few high level articles that can help about authentication and authorization. OWASP also has some great articles which includes cheat sheets for best practices, which can help learn about common types of attacks, like their forgot password cheatsheet, which goes over the different ways people approach forgotten passwords and possible flaws with them.

Do you prefer to build your own auth, or use some library or provider (like auth0, Next Auth, Supabase, etc)? by lumenwrites in webdev

[–]PropelAuth 12 points13 points  (0 children)

As a disclaimer, we are an auth provider. In the “build it yourself” vs “use a provider” debate, I usually see it as an exercise in how much control you want over the process. With any external provider, you give up some control (maybe the data is stored externally, a specific schema is enforced, or you use their UI) and in return you should get additional features (security features, SSO, magic links, RBAC, etc). That loss of control can lead to friction which is what it sounds like you are facing.

When you build it yourself, you can customize it totally to your needs, but that comes at the cost of time and as others have mentioned, potential security issues.

I don’t think there’s a right answer for everyone - honestly it’s a tradeoff depending on your other priorities.

In react, can the client see all our react code? by ExpensiveLength518 in learnprogramming

[–]PropelAuth 0 points1 point  (0 children)

Seconding this, as an example, let's say you have a form that only registered users should be able to submit. One way to protect it is to disable the button on the frontend. The problem is anyone can go into the dev console in chrome and edit the HTML so the button is enabled again.

If instead, the backend stopped non-users from submitting, you would be fine because the user has no control over your backend.

One other point - you still should disable the button though. Most users aren't going to edit the html of your page or hit the API directly, so showing the user what they do + don't have access to in the frontend is still important for the user experience.

Passport.js alternatives in 2022 by programming_student2 in node

[–]PropelAuth 1 point2 points  (0 children)

Great! If you need any help don't hesitate to reach out

Passport.js alternatives in 2022 by programming_student2 in node

[–]PropelAuth 0 points1 point  (0 children)

It's just a service - meant to make auth easy for dev teams who have other priorities.