Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement OAuth, OAuth2 and OpenID consumers #66

Closed
resurtm opened this issue Apr 1, 2013 · 19 comments
Closed

Implement OAuth, OAuth2 and OpenID consumers #66

resurtm opened this issue Apr 1, 2013 · 19 comments

Comments

@resurtm
Copy link
Contributor

@resurtm resurtm commented Apr 1, 2013

How about implementing OAuth, OAuth2 and OpenID consumers as officially supported extension(-s)? What do core developers and community members think about it? Are there any non-specific ideas and wishes?

Proposal from the 1.1 issue tracker: yiisoft/yii#306

Notable extensions:

Resources:

@qiangxue
Copy link
Member

@qiangxue qiangxue commented Apr 1, 2013

I think we better not include them as official extensions. Yes, they're useful, but then there are already many existing solutions which won't take developers too much trouble to use them in a Yii-based application.

@PrplHaz4
Copy link

@PrplHaz4 PrplHaz4 commented Apr 1, 2013

As a relative newbie to this framework, I'd just like to say that the sheer volume of extensions addressing this feature make it a bit of a crapshoot to navigate (and seem to show an obvious need). You could spend months reviewing the code for all such extensions trying to find one that fits the quality standards required (thereby eliminating the benefit of using an extension over writing it yourself).

The feature itself seems to be akin to providing the Web Services modules in Yii 1.1 core (admittedly, I don't know where that falls in Yii2) - which obviously required the core team to look at existing trends to try and understand what problems were worth giving a certain amount of effort to.

It would have definitely been a relief to see at least some core dev support of such an extension (or, even just an endorsement of quality - some indicator that it wouldn't be a bad decision to use a given extension - ok, maybe this is an extension problem in general, not an oauth problem ;)

I just think it's a potential pitfall to think that "there are many existing solutions" meaning the community is happy with the way it is working.

@qiangxue
Copy link
Member

@qiangxue qiangxue commented Apr 1, 2013

@PrplHaz4 You're right about the similarity of oauth support and the Web services in 1.1. My biggest concern is that these features require significant amount of efforts to reach good quality and maintain in future. Just take a look how much code they take. On the other hand, these features are very self-contained and there are indeed good solutions around (e.g. zend framework by which you can trust with its quality.)

We have to make a tradeoff between the quality of the core framework and the amount of useful yet unnecessary features that we want to support since our resource and energy is limited.

@yjeroen
Copy link

@yjeroen yjeroen commented Apr 22, 2013

@qiangxue, just a curiosity question. If a community member (outside of the team) forks and pushes a new feature like this.. Would you guys look at the quality of the code to decide if something like this would be accepted in the framework? Or would you still decide against implementing this in the core?

Something like this can easily be it's own extension; Im just wondering at which point would the Yii team decide to include it into the core. :)

@samdark
Copy link
Member

@samdark samdark commented Apr 23, 2013

I think it fits extension better regardless of the code quality.

@psihius
Copy link

@psihius psihius commented May 27, 2013

From my point of view these should be official Yii2 extensions. So that people still contribute to the central point and not splat their efforts all over the place and be left with a crapton of medium to bad extensions.
This also fits a lot of different areas, where a central official repository, still maintained by users, would consoledate the efforts and will have the ability to enforce code guidelines, code review and other stuff that will provide additional benefits.

Take me for example, I don't have enough time to do that many work on Yii, so that I get into core team, but in my line of work I deal with a lot of OAuth2, auth extensions (highly hacked srbac at this time), YiiExt and so on. And I actually have the ability to improve and provide push requests to such extensions and modules, to keep our own code base heathy. So do many others.

In this regard I like the ownership system PECL has on php.net - there are a few maintainers that develop the extension and people contrebute. If owner/owners disappear - via voting a new owner/owners are selected, if anyone is interested.

@qiangxue
Copy link
Member

@qiangxue qiangxue commented May 27, 2013

This also fits a lot of different areas, where a central official repository, still maintained by users, would consoledate the efforts and will have the ability to enforce code guidelines, code review and other stuff that will provide additional benefits.

This sounds convincing to me. @yiisoft/core-developers what do you think? Perhaps we should maintain a list of the so-called "commonly used official extensions" which are still maintained by users?

@samdark
Copy link
Member

@samdark samdark commented May 27, 2013

I'm for it. These could be yiisoft/something repos with permissions given to interested users.

@mdomba
Copy link
Member

@mdomba mdomba commented May 27, 2013

Can't agree more 👍

@lucianobaraglia
Copy link
Contributor

@lucianobaraglia lucianobaraglia commented May 27, 2013

Something like Officially supported extensions 👍

@nsanden
Copy link
Contributor

@nsanden nsanden commented May 27, 2013

Love this idea but seems lot of work just managing it all. Unless there could be some sort of voting on deciding which extensions get added / removed from official as well as the voting on managers of repos.

@klimov-paul
Copy link
Member

@klimov-paul klimov-paul commented May 28, 2013

Sure we need to have a list of official extensions for some most common tasks. But I do not know if there should be separated repository with different access rules for this.
GitHub provides “pull request” feature, which allows anyone to join the working on Yii project. Just look at @creocoder: his contribution to Yii2 is tremendous, while he is not an official member of @yiisoft.

As for OpenAuth / OpenId extension – it definitely should be in the core. Nowadays, almost all web application use these protocols to interact with external services, mostly with social networks. Yii should have both OAuth consumer and provider solutions.

@psihius
Copy link

@psihius psihius commented May 28, 2013

As I was mentioning already, see PECL - they have suitable model working pretty well.

I'm not goot with git, but as far as I know each extension/module has to have it's own owners, issue tracker and pull-requests. Is this possible with sub-repos or other mechanic? Or these should be repos listed on an official page and conforming to a set of rules. What are the options here?

@tonydspaniard
Copy link
Contributor

@tonydspaniard tonydspaniard commented May 28, 2013

That sounds a good idea but a couple of questions comes to my mind:

  • what would be the criteria for adopting an extension as official
  • would other contributions left aside just because they are not officially supported?
  • who is going to accept them as official extension? managing is certainly a lot of work as proven on Yii 1. ext.
  • why not writing some guidelines for an extension to be officially listed to get rid of badly written extensions?

About OpenAuth / OpenId agree with @klimov-paul for consumer and provider (to interact with social networks anybody can use something like http://hybridauth.sourceforge.net/userguide.html)

@PrplHaz4
Copy link

@PrplHaz4 PrplHaz4 commented May 28, 2013

I beleive the "official extension" discussion warrants its own issue, but will post my thoughts here for now.

Criteria for what makes it eligible to be "official":

  • Matching license
  • Needs code review from core team member (or by someone qualified*) - sponsor perhaps?
  • Fulfills common or popular pattern missing from core framework
  • Follows conventions used in yii blog (assumes yii-blog, or whatever new de-facto tutorial follows "best" practice)
  • 2+ active committers to prevent stagnation/keep current with framework updates
  • Decently vetted README - what it's for, example usage, alternatives, pros + cons, changelog

Contributions should not be left aside, as good ones should be considered for official status or will meet more niche standards

Accepted by community or core-team vote (when all criteria are present). Community vote will only be relevant if community is active and can not accept every addition without consideration. Management should be more involved for each extension, but proliferation of extensions should be reduced if there are official options - more attention is paid to fewer items.

Guidelines - yes please!

@klimov-paul
Copy link
Member

@klimov-paul klimov-paul commented Dec 9, 2013

What should be a name for such extension?

  • externalauth
  • authexternal
  • authconsumer
  • authclient

opinions?

@samdark
Copy link
Member

@samdark samdark commented Dec 9, 2013

Out of proposed variants I think authclient is the best variant. Second place goes to authconsumer.

@nineinchnick
Copy link
Contributor

@nineinchnick nineinchnick commented Dec 9, 2013

+1 to authconsumer, consumer better fits with OAuth terminology, auth and client are such common words

@psihius
Copy link

@psihius psihius commented Dec 9, 2013

My vote goes to authclient, as it represents exactly what it is.

qiangxue added a commit that referenced this issue Dec 25, 2013
Proposal for #66: auth client implementation
klimov-paul added a commit that referenced this issue Jan 1, 2014
tonydspaniard added a commit to tonydspaniard/yii2 that referenced this issue Jan 2, 2014
* upstream: (63 commits)
  doc fix.
  `yii\web\User::loginRequired()` now returns the `Response` object instead of exiting the application
  fixed test breaks.
  refactored Image helper.
  Reverted back the change to RequestPanel::save() as it causes issue.
  increase composer timeout setting for apps.
  refactored debug module
  Fixes yiisoft#1733: Incorrect code about `$_modelClasses` in `DbFixtureManager`
  doc fix.
  doc fix.
  Documentation for "authclient" extension has been extended.
  Doc comments at "yii\authclient\widgets\Choice" extended.
  bug fixes.
  removed unnecessary method
  debug module config panel improved
  Issues yiisoft#66 and yiisoft#1710 added to CHANGELOG
  OpenId::buildAxParams() fixed to add "openid.ax.required" parameter if required attributes are not empty.
  doc fix.
  Refactored imagine extension.
  SREG and AX param merging order at OpenId::buildAuthUrl() changed.
  ...
samdark pushed a commit that referenced this issue Jun 17, 2018
Doc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.