Oauthlib: Community members - activity

Created on 21 May 2019  ·  33Comments  ·  Source: oauthlib/oauthlib

Hi @oauthlib/core-contributors, I would like to propose that all majors downstream players to have a role in the oauthlib group.

Without them, the framework would not survive and we see that new features are implemented in the downstream libraries instead of the oauthlib framework itself. If the oauthlib community can have more active members, it will be beneficial for everyone.

Given the active downstream libraries list below:

  • @jazzband/django-oauth-toolkit
  • @singingwolfboy/flask-dance (includes @requests/request-oauthlib)
  • @thomsonreuters/bottle-oauthlib (it doesn't count, that's me)

My proposal is:

  • add all downstream's admins as oauthlib's admin
  • add each downstream's contributors as oauthlib's write access

I think it's vital to give enough space for the oauthlib framework to breath.
What do you think ?

Ping @singingwolfboy, @daenney, @jleclanche, @synasius, ... ?

Discussion

Most helpful comment

@denizdogan @duaneking Auth0 is just one sponsor of Authlib, it has nothing to do with "control" "manage" "license" or any other things of Authlib. You can consider it as an advertisement.

Auth0 has tried to contact me to create an integration for them specifically, but I've refused that. You won't see any auth0 related code in Authlib. I don't understand why that is a problem, the information is public, you can get the money information through https://www.patreon.com/lepture. Anyone can support me through patreon or GitHub.

Besides that, you can also see there is another sponsor Authing on readme.

And OAuthlib itself is also using a Auth0 sponsored library: https://pyjwt.readthedocs.io/en/latest/

All 33 comments

I'd actually be in favor of moving d-o-t to oauthlib org. It's currently in jazzband which is more or a FFA contribution org. I suggested moving it there initially as it was essentially unmaintained in its original org.

I don't mind having write access but I don't expect I'll be needing it. Though I'm pretty familiar with Flask and feel comfortable contributing to Flask-Dance directly by handling issues, merging PRs etc. I can't claim that same familiarity with OAuth and the OAuth spec. Though I can participate in issues and code reviews, I don't feel I'd be comfortable pressing the merge button on a PR on oauthlib aside from very trivial changes.

@jleclanche, despite the maintenance work (docs, tooling, links,...) around moving a project into oauthlib org, I think it is a good idea & can be worth it long term. I think we could move bottle-oauthlib into the org, too.

@daenney, that's perfectly fine ! I don't expect any downstream developers to know everything about OAuth, but we have the python API between the libs and oauthlib. You are certainly have a word on this, and reviewing this part -the API- can be very beneficial for Flask-Dance & others.

This seems reasonable to me! I don't spend a lot of time working on Flask-Dance these days, since I'm not using it for anything at the moment, personally or professionally. Nonetheless, I'm still actively supporting it, and @daenney has been a huge help. (Thanks again!)

I'm not sure I'll actually be doing much with requests-oauthlib, but it's definitely good to have the permissions to do so. One more question: I recently learned about Tidelift, and I've signed up with their platform as a maintainer for Flask-Dance. I suppose I should do the same for requests-oauthlib? Does anyone have a problem with that?

To be honest, if I get the time and the motivation, I'd like to rewrite the requests-oauthlib codebase and documentation -- it's not very nice to work with. But related to my earlier point, I'm not sure when or if I will ever get around to doing that.

@singingwolfboy, no concerns about Tidelift.

If nobody has an objection, I'll give a couple of write access to this project in one week. Poke @thedrow, @skion, @duaneking, @wiliamsouza.

I'm in favour of this as I'll be able to spend less time going forward.

I would like to display the GitHub Sponsor button on the requests-oauthlib repository, but I don't have permission to access the settings page of that repo on GitHub. Can someone please turn it on, or give me permission to turn it on myself?

I have invited a couple of downstreams contributors into oauthlib org. If I miss anyone, OR if anyone reading this discussion is interested in participating into oauthlib, either on behalf of another downstream library or on his own, please comment here or send me a message!

Thanks

@singingwolfboy Please edit the FUNDING.yml file accordingly.

@thedrow Could you please clarify your comment?

  • _Which_ FUNDING.yml file are you referring to?
  • How would you like me to edit it?
  • Are you able to make a pull request, so that you can demonstrate the edits you think should be made?
  • Finally, does this discussion even belong in this particular GitHub issue?

poke @singingwolfboy, I saw that you have write access to requests-oauthlib, do you know who can grant to some of us similar permissions ?

I think if I find some spare time to clean the issues/PR, I will.

CC'ing @jezdez here; reached out on IRC about moving DOT from jazzband to here.

@jleclanche, @jezdez, any progress so far?
@singingwolfboy, any updates on requests-oauthlib ownership/write access?

Thanks

@JonathanHuot: I believe @sigmavirus24 gave me access to the requests-oauthlib repo, but it seems that he is on hiatus from open source development, for an indefinite length of time. Seems like the best option here is to use the support channels documented on the Requests website. In my experience, IRC works best if you can find a time when a maintainer is online: #python-requests

In related news, @jtroussard indicated to me that he is interested in becoming a maintainer as well, although he doesn't have much experience with open source. He and I are going to find a time to videochat, so that I can answer his questions and help him get started as much as I can.

I've not received an answer from @jezdez in moving DOT out of jazzband. Can someone who would follow up on it file an issue here?

Hi friends, sorry for keeping you all waiting, I want to clarify a few things since django-oauth-toolkit hasn't be in Jazzband for a very long time. In the interest of Jazzband's "open door" policies (basically everyone can join the Jazzband GitHub org and directly contribute), getting approval for moving django-oauth-toolkot to the oauthlib organization from everyone having contributed since the move to Jazzband seems like a sensible check to make.

I would also recommend getting confirmation for the move from @synasius (who moved the repo to Jazzband from its previous location) and the current project lead @MattBlack85 who graciously stepped up a while ago to lead the project.

Here's a list of the changes that happened since the day of the move to Jazzband including the contributors that did the changes: https://github.com/jazzband/django-oauth-toolkit/compare/master@%7B04-18-18%7D...master

@jleclanche Since you were one of the contributors and have asked on IRC and here about the move to the oauthlib org, would you mind doing some of the leg work reaching out these people here in the ticket to get confirmation?

I'm currently away until the 5th of December. I'm happy to do some legwork after that date to help out!

I just spoke to @denizdogan, and he's also interested in helping out with requests-oauthlib. He and I both believe that the existing code is in a bad state, and a ground-up rewrite might be a good idea -- which also allows us to create a nicer developer API. He's going to create a new repository and start working on a new project which _may_ end up replacing requests-oauthlib at some point in the future.

Maybe the project can also support httpx for async connections?

@thedrow That's actually what I'm working on in my spare time, basically just a rewrite of requests-oauthlib but using httpx and possibly implementing other improvements as I find them. The working name is uninterestingly httpx-oauthlib (no code online yet).

To be open and honest about it, I'm doing this mainly to figure out why requests-oauthlib has been designed the way it has been and to see if I could do any better with 20/20 hindsight and with no requirements of backwards compatibility. Don't let my working on this stop anyone else from doing the same thing, because you're probably better suited for the task than I am anyway. :)

If I end up with a proper package on PyPI, httpx users would be the main target audience and requests would maybe be used as a fallback, depending on how much work it would entail.

This might be a silly question, but I need to ask:

Is there anything lacking in Authlib now? I thought it was only for writing OAuth servers, because it really pushes that part in its tagline, but it seems like nowadays it has not only client support, but also Flask and Django integrations, async HTTPX support, PKCE support, OpenID Connect, etc. It's currently being actively developed by @lepture since he created a fork more than two years ago.

I'm kicking myself a bit for not taking a closer look before, because I've been spending quite a few hours of my free time making httpx-oauthlib, but that seems superfluous now. The way they've designed Authlib is very much in line with what I was trying to accomplish, and sometimes actually better than what I had in mind.

Dare I say that maybe it's time to think about deprecating oauthlib and requests-oauthlib and focus on Authlib?

No.

Auth Zero is a private company that cant be trusted; They are funding that effort and I personally view it as an attack on the community because they are involved.

I joined this project originally because Auth0 as a company was abusively trying to buy and leverage its way into ownership or control of every possible login library because to them its best to have less competition; They have simply kept doing that in an effort to raise prices on startups and try to control login as a service and force companies to use them, so I do not trust them at all.

As a result, we NEED this project to exist as a simple way to assure that they don't control everything; Their stuff tends to break if you are not using them officially so I see them as the BORG.

@duaneking I understand - I was not aware of Auth0's business practices or even that they were associated with Authlib. I appreciate your response and will reconsider the idea of using Authlib. That being said, from what I could find, Auth0 is merely a "sponsor" of the project and Hsiaoming is running their own business which is otherwise unrelated to Auth0. Is my understanding correct or does the rabbit hole go deeper?

No.

Auth0 does that "sponsorship' in a few ways, what you seeing is the front end part. You should consider any dev actively taking money from them either directly or indirectly through a project to be tainted/controlled/influenced by them on the backend as well as it's not uncommon for companies to force devs to sign agreements they can't talk about in public in order to direct branding and mitigate risk to the company etc.

When they tried to reach out to me, that was exactly what was offered, and as a result, I have zero trust for any project that they "sponsor" or "support" and the devs themselves who have agreed to that are also suspect as they have effectively sold their credibility in my opinion.

@denizdogan @duaneking Auth0 is just one sponsor of Authlib, it has nothing to do with "control" "manage" "license" or any other things of Authlib. You can consider it as an advertisement.

Auth0 has tried to contact me to create an integration for them specifically, but I've refused that. You won't see any auth0 related code in Authlib. I don't understand why that is a problem, the information is public, you can get the money information through https://www.patreon.com/lepture. Anyone can support me through patreon or GitHub.

Besides that, you can also see there is another sponsor Authing on readme.

And OAuthlib itself is also using a Auth0 sponsored library: https://pyjwt.readthedocs.io/en/latest/

I don't trust Auth0. Their tactics are in my mind, unethical. The fact they want to throw money around is fine but that should NEVER give them ANY control or even influence.

Their goal of reaping profits per user on startups and charities (or on anybody) is antithetical to the community, any companies goals, etc, and they should be seen as hostile to the community by their very nature as a company that wants price per user to be as high as possible in order to provide for their bottom line. Their very business model is an attack on open source, startups, any company, etc imho.

Dare I say that maybe it's time to think about deprecating oauthlib and requests-oauthlib and focus on Authlib?

For what it's worth, the main feature OAuthlib has over Authlib is an agnostic approach.


Tangent
Authlib's httpx integration is a version behind, which a small but nonzero concern. Two PRs have been filed (and closed) on this issue: lepture/authlib/pull/219, lepture/authlib/pull/209.

I also have a small, but nonzero concern over @lepture's copyright assignment policy. It's 100% understandable as a library consumer, but I as a contributor, I would just prefer releasing under CC0. I haven't discussed that with them in detail, though.

I'm not a fan of one person owning an entire communities work, myself.

I'm interested in becoming a maintainer.

Hi @auvipy, you are more than welcome to the project, I sent an invite !

Hi @auvipy, you are more than welcome to the project, I sent an invite !

got it. but no merge or approval right now.

Can you check again ? I think I was confused about org, team and project. Now you and everyone in the oauthlib org should have more permissions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ggiill picture ggiill  ·  7Comments

JonathanHuot picture JonathanHuot  ·  10Comments

ViktorHaag picture ViktorHaag  ·  11Comments

potiuk picture potiuk  ·  14Comments

jcampbell05 picture jcampbell05  ·  14Comments