Implement OAuth, OAuth2 and OpenID consumers #66

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

Comments

Projects
None yet
@resurtm
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Apr 1, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@PrplHaz4

PrplHaz4 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.

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

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Apr 1, 2013

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@yjeroen

yjeroen 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. :)

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

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 23, 2013

Member

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

Member

samdark commented Apr 23, 2013

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

@psihius

This comment has been minimized.

Show comment
Hide comment
@psihius

psihius 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.

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

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue May 27, 2013

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark May 27, 2013

Member

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

Member

samdark commented May 27, 2013

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

@mdomba

This comment has been minimized.

Show comment
Hide comment
@mdomba

mdomba May 27, 2013

Member

Can't agree more 👍

Member

mdomba commented May 27, 2013

Can't agree more 👍

@lucianobaraglia

This comment has been minimized.

Show comment
Hide comment
@lucianobaraglia

lucianobaraglia May 27, 2013

Contributor

Something like Officially supported extensions 👍

Contributor

lucianobaraglia commented May 27, 2013

Something like Officially supported extensions 👍

@nsanden

This comment has been minimized.

Show comment
Hide comment
@nsanden

nsanden May 27, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@klimov-paul

klimov-paul May 28, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@psihius

psihius 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?

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

This comment has been minimized.

Show comment
Hide comment
@tonydspaniard

tonydspaniard May 28, 2013

Contributor

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)

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@PrplHaz4

PrplHaz4 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!

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

This comment has been minimized.

Show comment
Hide comment
@klimov-paul

klimov-paul Dec 9, 2013

Member

What should be a name for such extension?

  • externalauth
  • authexternal
  • authconsumer
  • authclient

opinions?

Member

klimov-paul commented Dec 9, 2013

What should be a name for such extension?

  • externalauth
  • authexternal
  • authconsumer
  • authclient

opinions?

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Dec 9, 2013

Member

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

Member

samdark commented Dec 9, 2013

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

@nineinchnick

This comment has been minimized.

Show comment
Hide comment
@nineinchnick

nineinchnick Dec 9, 2013

Contributor

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

Contributor

nineinchnick commented Dec 9, 2013

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

@psihius

This comment has been minimized.

Show comment
Hide comment
@psihius

psihius Dec 9, 2013

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

psihius commented Dec 9, 2013

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

@qiangxue qiangxue closed this in #1620 Dec 25, 2013

qiangxue added a commit that referenced this issue Dec 25, 2013

Merge pull request #1620 from klimov-paul/authclient
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

Merge branch 'upstream'
* 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 #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 #66 and #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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment