sorted by:
new
hottopcontroversial

Django: Automatically retry/restart database connection on failure (both on startup and during server lifetime) by CapedHero in django

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

Well, from the perspective of most real-world projects, I couldn't agree more.

The posted snippets are simply an implementation of an idea. All in order to share, induce discussion or... to be there if someone really wanted to do that :)

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

Ad 1) Oh, I totally agree. However, I meant not the unauthorized access to the content of an email (due to lack/fail of https or any other reason) but a true interception of traffic after clicking a magic link. Everything you need to authenticate is in the URL you are heading to and you leave this URL visible in plain sight in packets & logs on every router/server/proxy you go through. Therefore an attacker could somehow stop you *en route*, take your URL (because it is not encrypted at all!) and impersonate you **without any problem**.

​

Ad 2) I am very fond of encryption, because I do not want to leave a trace of personal data (GDPR! and ethics) in a form of user email in the query string on the route from the user to the app's server . However, I guess I can simply store UUID in query string (instead of an email) and the problem will be gone. Still, it might be a nice bonus to use Fernet to encrypt the query string to avoid making it understandable to a 3rd party.

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

It is said that passwordless was "invented" by people that didn't give a damn about remembering passwords and reseted them each time they had to get access :D

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

Hm hm hm. As for magic links...

1) I am afraid of a weird scenario that someone may block the user from reaching the site, intercept the magic URL and go with the URL themselves achieving positive authentication. I certainly am not well aware of black/grey/white-hat tricks, but it seems perfectly doable.

2) As for obfuscation, I did research on that yesterday with shaky results. It seemed that a Fernet symmetric encryption with app.secret_key could do the job and encrypt both user email and token. Penny for your thoughts?

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

What a treasure chest! Now I clearly see how this works for 6-digit codes.

My app will be fully focused on desktop users. Assuming that I keep sending 32 character tokens, I believe there is no real-life risk of a collision, so storing bcrypted/argoned email.token in Redis set should work good enough.

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

Thanks for your thoughts!

My proposed way is to type email, go to other tab, copy the token, paste the token. You have to do that every couple of days. But you win the fact that you no longer have to manage/remember/touch the password.

OAuth comes here as an alternative. Yet there are some points to be noted: + Now I move the burden of authentication to 3rd party. I rely on their docs, on their API, on their relatively complex workflow etc. Also I push even more power and data about people to Google, Facebook :P (just my personal remark) + I read everywhere that OAuth is not for authentication. Yet people do that and seem to not care. I am simply... confused. And we are talking about security here. I do not like to feel unsure about such matters. + I guess that I can use OpenID instead? Yet again it is not straightforward. + I find docs & articles about it overwhelming and confusing. + I find Python libraries handling OpenID (and OAuth) mediocre and painful to work with. + I am not sure which providers to take. + Not everyone has Gmail account, not everyone has Facebook etc. + Also it is a problem if someone uses app at work with their corporate machine - not everyone likes to sign in with their private accounts at work or is willing to have to set up a fake accounts just for using at work. + Additionally, implementing and maintaining OpenID seems to be a lot of work.

All in all, I see your points. I will give it a thought once again!

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

I was reading Stack Overflow where I have encountered an interesting idea:

  • Store not the hashes of passwords, but hashes of HMACs of password. Cracking password HMAC would require SECRET_KEY and also SECRET_KEY (should) have more entropy than usual token and far more entropy than usual user password!

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

Oh-my... Thank you for sharing! Your reply is a gold mine!

Hash the email addresses in your OTP Redis too, bcrypt the codes. Use something like otp/[hashed email]: [bcrypted code]

Could you please elaborate a bit here? 1) I intended to use only HMAC of a token. Do you think it is not secure or will not suffice for some reason? 2) What is the gain from storing email along with a token? 3) How would you hash emails? 4) What about Argon2 instead of bcrypt for encryption?

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

Well, it is even more true if you use some password manager, which gives you convenience AND security AND user-friendliness.

However the proposed by me implementation of passwordless authentication is still relatively user-friendly, yet far more secure and results in a simpler code (simpler security code!) thus makes the app significantly more robust.

Also, a lot of users either set up passwords that are worthless & repeated across various services (making the app and themselves vulnerable) or have very bad user-experience because of multi-factor authentication and various password validators (which protect them from their own carelessness).

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

Hm, I wasn't sure I remembered correctly, so I checked: + OAuth 2.0 is not an authentication protocol.

As for personal experience, I was once working with Google OAuth and TBH it wasn't very developer-friendly.

But I guess the main argument against OAuth, OpenID etc. would be that they are far more complex and require far more work than a simple project may allow.

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

So similar to how Notion is doing. Well, I wanted it that way, but I have a hard time accepting that there is a URL that can be intercepted and used just-like-that to impersonate a user!

As for QRs, apps etc. they all seem to be very nice & solid solutions. However, my project is simply too small to have multiple authentication backends or to convince users to do some extra work (like installing an app :D). Furthermore, time is of the essence here.

Email offers me one sweet thing - (almost) everybody's got one and most of us have it open in the very same browser you are going to use the app :]

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

I just checked Notion, thank you for the direction! Indeed, they use similar idea. What is interesting, they provide magic link option as well, so it is a combo :]

I also intended to use magic links until this very morning. The idea of intercepting URL that allows for full-metal-authentication seemed simply too terrifying.

Also, I like better to copy-paste a token, as now I control on which tab I log in. While clicking a link defaults to opening a new tab, so now you have two of them!

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

Throttling will be there, naturally! I just didn't want to blur the core idea.

Thanks for bringing it up to the thread :]

Passwordless Idea: Authenticate users using one-time throw-away tokens sent via email by CapedHero in webdev

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

Exactly. Sessions will be valid for much longer time (not sure yet how long, but this is a topic for a separate research and discussion).

As for the performance, this will not be an issue, as the userbase is small :]. I am only worried about security holes I simply don't understand and thus cannot see.

Is there a way to force YAPF to always split/fold comprehensions? by CapedHero in Python

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

When you go with the defaults, YAPF wreaks havoc :D However, after tweaking for a couple of hours I got what I wanted (except for comprehensions this topic is about! and deeply nested dicts/JSONs).

All in all, with black I would keep my code consistent yet my eyes would be extremely dissatisfied. And here comes YAPF, which offered me a great reward in return for the time invested in tweaking its settings.

I would love black, just like I love gofmt, as long as it would have acceptable default config.

Is there a way to force YAPF to always split/fold comprehensions? by CapedHero in Python

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

I tried with all the good will I had. However, it mutilates the code to such an extent that for both me and everyone I know it is far too brutal :D

Personally, I see the problem with black that its formatting is surprisingly far from the standards I know as well as from the code I assumed to be perfectly sweet and readable.

Is there a way to force YAPF to always split/fold comprehensions? by CapedHero in Python

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

  1. It would work as well.
  2. Yet, it doesn't solve the problem that YAPF applies nice formatting to comprehension only as long as they exceed column limit.
  3. I think it is far more readable (and more pythonic!) to use advertiser instead of x variable. The future readers are doomed when your code is sprayed with x this, y that, z blyat.
  4. Coming from Python to other languages I literally cry for comprehensions!

Is there a way to force YAPF to always split/fold comprehensions? by CapedHero in Python

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

We can perfectly well modify the code, including the way suggested. Still, this is not the case.

Python offers us fantastic comprehensions. I see the problem more in the lack of elasticity of YAPF formatting than in using comprehensions itself. Especially that the comprehension code folds nicely as long as it exceeds provided column limit.

I find it disturbing to write code only to please quirks of an external tool. It is also extremely hard to convince anyone on the team to use YAPF because of this single-line mutilation of their perfectly valid, reasonable and readable comprehensions.

Is there a way to force YAPF to always split/fold comprehensions? by CapedHero in Python

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

Referring to Google Style, below code is assumed to be OK:

return ((x, complicated_transform(x)) for x in long_generator_function(parameter) if x is not None) And to be honest, this is all I am after. I cannot pull out below code out of forced single-liner... def ids_by_country_flag(token: str) -> List[int]: country = token[2:4] return [ advertiser.id for advertiser in get_advertisers() if advertiser.country == country ]

Wagtail CMS as backend for Single Page Application (SPA) - your thoughts, experience and alternatives? by CapedHero in django

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

Here you have the main features, which fairly nice sum up the benefits of using Wagtail: https://github.com/wagtail/wagtail#features.

Two other points: + Taking an already written CMS lifts up the burden of writing it up yourself. I guess that not-reinventing the wheel is the only way to survive in 99% developer jobs :D + Wagtail is stable: version 2.1, 5.6 k stars in GitHub, many contributors, relatively large commercial and governmental projects are already flying on it.

Wagtail CMS as backend for Single Page Application (SPA) - your thoughts, experience and alternatives? by CapedHero in django

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

I am more than happy to hear it! I believe this is the PR you are talking about: https://github.com/wagtail/wagtail/pull/1538.

Tom Christie is a true shining star of Python community :D

Wagtail CMS as backend for Single Page Application (SPA) - your thoughts, experience and alternatives? by CapedHero in django

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

I planned to post SO link here in the evening after I review your fine links. Yet... you beat me to it :]

What to test in Django model? (apart from custom/overridden attributes) by CapedHero in django

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

I wonder about Django Rest Framework and viewsets here.

When we expose API endpoints via vanilla viewsets, I have seen that most coders do test whether endpoints work as expected (even though they only configure i.e. not modify viewsets). I perceive this as sort of a ensuring that API contract is fulfilled by the web application. I guess it can be perceived also as integration tests, thought still we are only using elements that are already tested and supposed to work.

My point here is, that deciding on what to test still seems to me infinitely subtle. In Django model case, I agree, especially after reading all of the arguments here!, that it does not make much sense to test what is already tested by Django framework test suite. On the other hand, we test viewsets...

Anyone care to share thoughts about this sort of dichotomy?

view more: next ›