Hi Vineeth. There are a few third-party options in the space already. (Some linked from the thread I mentioned above. Others easily found via Google, "django 2fa".) I'd begin looking at those.
I will write up a proper page for GSoC with the ideas here over the holiday period, but if you want an early start look at the "Students" section (and the following ones) from last year's page: https://code.djangoproject.com/wiki/SummerOfCode2019#Students Start looking at this: https://docs.djangoproject.com/en/dev/internals/contributing/ Make sure you're up and running with a development environment. Get to know Trac, even if only a little bit. And hang-out here and on the Forum https://forum.djangoproject.co — I want to leverage that for comms in 2020. Above all have fun! :) Welcome aboard Kind Regards, Carlton On Thursday, 19 December 2019 09:46:45 UTC+1, vineeth sagar wrote: > > Hi Carlton, > > I don't know if this is appropriate here or not. I will be starting > Master's this spring 2020(Jan) > > > I love the idea of 2FA. For first iteration I have an idea. While creating > a user we can ask for a 6 digit pin and whenever someone tries to login we > can make them input this pin. I have seen this implemented by a few > companies like Zerodha, UPI in India, these have a big customer base as > well. We can move towards more complicated ones with this as a starting > point. > > Moreover is there a reading list on what's expected of the 2FA, So I can > start drafting a proposal for this. I'll look at the rfc mentioned in the > thread for motivation and how it can be integrated to django. If there are > other latest sources it will be helpful. > > > Best, > Vineeth > > > On Thu, 19 Dec, 2019, 1:39 PM Asif Saif Uddin, <auv...@gmail.com > <javascript:>> wrote: > >> As a long term user of django, I would love to see the DB/ORM + HTTP >> related improvements more in django and the schema migration improvements >> as I use django mostly for ORM and API/CMS based projects. >> >> I like the proposals of Adams related to ORM and inclusion of >> django-cors-headers to core. >> >> Beside the Idea of supporting 2FA, I think django should think about >> providing oauth2 support out of the box based on oauthlib and >> django-oauth-toolkit :) >> >> Definitely there could be better packages :) >> >> Just my thoughts as an long term user of django framework. >> >> Thanks, >> Asif >> >> On Thursday, December 19, 2019 at 4:51:06 AM UTC+6, Adam Johnson wrote: >>> >>> This year was interesting. Sage in particular did well putting together >>>> a cross-db JSONField, but he was probably under-mentored, >>>> since Mariusz has spent quite a bit of time reworking the PR, and still >>>> has a bit to go, before we can pull it in, hopefully for 3.1 >>>> >>>> So, one consideration we need to think about seriously is our capacity >>>> for mentoring. (This isn't just about the candidate's ability — Sage was >>>> able to implement all suggestions — we just didn't have as much capacity >>>> as >>>> we might have liked to think about the requirement implementation — and >>>> there were four of us actively giving some time each... — Anyhow, to think >>>> about.) >>>> >>> >>> I think your analysis is pretty accurate Carlton. Sage was a pretty >>> self-motivated candidate, writing some great blog posts about his code, and >>> we still didn't manage to merge his PR. Perhaps the project was larger than >>> we can reasonably expect? >>> >>> Nice work on the descriptions there Andrew. >>> >>> Django Service Hooks >>>> >>> >>> I think a key use case of this is background task processing. Nearly all >>> the Django integrated libraries need to remember to "connection.close()" / >>> "close_old_connections" at the end of requests. I've seen a couple in-house >>> ones that needed this. >>> >>> That said I can't think of much else to go inside the "service hook"? >>> There's not much else to "the end of a Django context" at the moment is >>> there? >>> >>> Evented Datastores >>>> >>> >>> I'm not sure if other databases have it but MariaDB recently implemented >>> "temporal tables" which are an SQL standard way of doing historical views >>> on data: https://mariadb.com/kb/en/library/temporal-data-tables/ >>> >>> Admittedly not quite the same as event sourcing but perhaps easier to >>> implement given it would be limited to the ORM layer. >>> >>> Django Benchmarking >>>> >>> >>> I love djangobench, and do wish it was maintained and expanded. Running >>> on CI would be amazing. >>> >>> >>> 2FA also sounds like a great idea. >>> >>> Other ideas: >>> >>> - Support MySQL/MariaDB storage engines. I think other databases >>> tend to support some table-level customizations to. >>> - Official CORS middleware/view decorator. I took over maintenance >>> of https://github.com/adamchainz/django-cors-headers and its design >>> is a bit pants. >>> >>> >>> On Sat, 14 Dec 2019 at 17:30, Andrew Godwin <and...@aeracode.org> wrote: >>> >>>> Here's my take on each of these, leaving out async as that'd be more >>>> dependent on where we were: >>>> >>>> Secrets Manager >>>> Many environments Django is deployed in use a separate secrets manager >>>> to store and provide secrets per environment - either as environment >>>> variables, files, or via a direct HTTP API. The project would be to design >>>> and add an abstraction interface over secrets managers that allows users >>>> to >>>> easily map to an external secret in a settings file. There's also room for >>>> giving Django a better, built-in per-environments settings option too, >>>> pulling from popular third-party patterns. >>>> >>>> Django Service Hooks >>>> Django has a lot tied to the HTTP lifecycle, and if you run it outside >>>> of this, you miss out on some key things - like database connections being >>>> closed properly, or logging, or some middleware. The project would be to >>>> design and implement a separate way of calling Django from a service >>>> framework - even if that framework was itself HTTP based (basically, don't >>>> rely on Django having to run through WSGI/ASGI). Initial idea is to >>>> provide >>>> a context manager that replaces the wrapping of a request, but the project >>>> would have to include requirements-gathering and interviewing people who >>>> use Django to power microservices to work out what they want. >>>> >>>> Evented Datastores >>>> Evented, or event-sourcing, database schemas are growing in popularity >>>> - essentially, a way to implement an append-only pattern on top of a >>>> relational database, where every single event that has happened is stored, >>>> but you can still efficiently retrieve the current state of an item. Given >>>> the way the pattern works, this would be possible to implement on top of >>>> Django models - likely as a whole new Model subclass - and implement with >>>> a >>>> matching QuerySet/Model API. It would require someone very skilled in >>>> database design, and it's also arguable if it should be in Django itself, >>>> or comprise of developing a third-party app alongside adding hooks/fixes >>>> to >>>> the Django ORM where needed to make it work well. >>>> >>>> GraphQL >>>> Basically, work on an "official" graphql-to-ORM mapper for Django, >>>> probably re-using a considerable amount of third-party work. This one >>>> could >>>> really vary in its application, based on how much other "API-ish" work the >>>> project includes (given that Django REST Framework is still separate, we >>>> should follow that rough pattern). >>>> >>>> Plus, some bonus ones that aren't Django code itself: >>>> >>>> Django Case Studies >>>> Our long-talked-about website which brings together case studies and >>>> white papers about why people choose Django, aimed at companies working >>>> out >>>> what they want to choose. This is likely only some coding and a lot of >>>> writing/legwork, so may not be a good fit for GSOC, but should be on any >>>> future plan we have. >>>> >>>> Django Benchmarking >>>> Django has had a benchmarking suite for a while, but we've generally >>>> got more slack at tracking the effects each commit and release has. We >>>> should institute a set of top-level benchmarks aimed at various areas (the >>>> current set in djangobench are weak in, say, the HTTP-serving-speed area) >>>> and then run them against pull requests and each release, so we can make >>>> sure Django doesn't get slower while nobody is looking. >>>> >>>> I'm sure there's a lot more, but these are top of mind at the moment! >>>> >>>> Andrew >>>> >>>> >>>> On Tue, Dec 10, 2019 at 11:52 AM Carlton Gibson <carlto...@gmail.com> >>>> wrote: >>>> >>>>> Hey Andrew. >>>>> >>>>> Yes, Async, of course. It's not until *next July* so I'd still think >>>>> we should list this. Worst case is there's exactly zero progress between >>>>> now and decision day, in which case you could say that we could only >>>>> accept >>>>> a clearly capable candidate. (Jannis was once our GSoC person, so... :) >>>>> >>>>> The other ideas seem good: the secrets manager abstraction is a nice >>>>> one (!) >>>>> >>>>> No rush, but when you have a moment, perhaps you could draft a couple >>>>> of paragraphs for each? (Even if they don't go to GSoC directly, it would >>>>> come in handy for the TB's direction guidance...) >>>>> >>>>> Kind Regards, >>>>> >>>>> Carlton >>>>> >>>>> >>>>> On Tuesday, 10 December 2019 19:14:51 UTC+1, Andrew Godwin wrote: >>>>>> >>>>>> I agree that 2FA could be a good choice - some of the async support >>>>>> work would also have been good, had I made more progress in the latter >>>>>> half >>>>>> of this year. >>>>>> >>>>>> A couple of other ideas for big projects: >>>>>> >>>>>> * A secrets manager abstraction and built-in support for Vault, KMS, >>>>>> and other common ones >>>>>> * A proper story and hooks for running Django as a service (i.e. >>>>>> outside of a traditional HTTP request/response cycle) >>>>>> >>>>>> And some ludicrous projects I'd still consider: >>>>>> >>>>>> * Evented/event-sourcing database work on top of the ORM >>>>>> * A GraphQL-to-ORM mapper >>>>>> >>>>>> Andrew >>>>>> >>>>>> >>>>>> On Tue, Dec 10, 2019 at 8:25 AM Carlton Gibson <carlto...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi all. >>>>>>> >>>>>>> It's time to start thinking about Google Summer of Code (GSoC). If >>>>>>> we're going to participate and projects we might propose. >>>>>>> >>>>>>> This year was interesting. Sage in particular did well putting >>>>>>> together a cross-db JSONField, but he was probably under-mentored, >>>>>>> since Mariusz has spent quite a bit of time reworking the PR, and >>>>>>> still has a bit to go, before we can pull it in, hopefully for 3.1 >>>>>>> >>>>>>> So, one consideration we need to think about seriously is our >>>>>>> capacity for mentoring. (This isn't just about the candidate's ability >>>>>>> — >>>>>>> Sage was able to implement all suggestions — we just didn't have as >>>>>>> much >>>>>>> capacity as we might have liked to think about the requirement >>>>>>> implementation — and there were four of us actively giving some time >>>>>>> each... — Anyhow, to think about.) >>>>>>> >>>>>>> Then it's projects. There are three that I have on my list that >>>>>>> would require a "competent candidate": >>>>>>> >>>>>>> 1. Work on the migrations. Markus mentioned a particular ticket here >>>>>>> but... >>>>>>> 2. Make the parallel test runner work on Windows. ("fork" vs "spawn") >>>>>>> >>>>>>> And 3, and this is the big one: >>>>>>> >>>>>>> 3. Add 2FA to Django. >>>>>>> >>>>>>> This has been raised a few times: >>>>>>> >>>>>>> * >>>>>>> https://groups.google.com/d/topic/django-developers/T-kBSvry6z0/discussion >>>>>>> * >>>>>>> https://groups.google.com/d/topic/django-developers/d92P2V0YrbI/discussion >>>>>>> >>>>>>> * ... others... >>>>>>> >>>>>>> If I'm honest, in 2020, it's the one "battery" I feel a little bit >>>>>>> embarrassed we haven't got a story for. Maybe it's not possible in a >>>>>>> GSoC >>>>>>> type scope but... >>>>>>> — What would it look like? What can we leverage? Is it worth a go? >>>>>>> >>>>>>> I'm looking at James, Florian, Joe, ... — who else has been keen >>>>>>> here? >>>>>>> I'm also looking at the Technical Board, which I'm thinking has >>>>>>> (will have) a new guiding role to come up with suggestions for the >>>>>>> direction of Django. >>>>>>> >>>>>>> >>>>>>> Other Projects: Are there other ideas? (Do you have one?) Are there >>>>>>> easier things that we could take "weaker" candidates for? But with that >>>>>>> is >>>>>>> there a commitment for the mentoring help they'd need? >>>>>>> >>>>>>> Anyhow, we have until January, so I'm just starting the discussion >>>>>>> here. >>>>>>> >>>>>>> Kind Regards, >>>>>>> >>>>>>> Carlton >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Django developers (Contributions to Django itself)" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to django-d...@googlegroups.com. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/django-developers/af075d59-ece3-4044-9204-b690c746b9e0%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/django-developers/af075d59-ece3-4044-9204-b690c746b9e0%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Django developers (Contributions to Django itself)" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to django-d...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/django-developers/e1818353-9fa0-4e49-a6e9-4757f06c7e19%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/django-developers/e1818353-9fa0-4e49-a6e9-4757f06c7e19%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers (Contributions to Django itself)" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to django-d...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/CAFwN1uqaniLZayw19gKOzEi3KT2EqD8VD-3%3Dd77FExQaYEUVYw%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/django-developers/CAFwN1uqaniLZayw19gKOzEi3KT2EqD8VD-3%3Dd77FExQaYEUVYw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> Adam >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-d...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/8e15ba2f-4c84-47de-974d-27a36147e426%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/8e15ba2f-4c84-47de-974d-27a36147e426%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fed76572-3230-441a-8a39-c5ad16ece8ce%40googlegroups.com.
