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

support social logins #8

Open
mgenev opened this issue Mar 1, 2015 · 3 comments
Open

support social logins #8

mgenev opened this issue Mar 1, 2015 · 3 comments

Comments

@mgenev
Copy link
Member

mgenev commented Mar 1, 2015

No description provided.

@Globegitter
Copy link
Member

This could potentially be sub-plugins or be installed via flags: sane install sane-auth --social. There should definitely be some way to turn it on/off.

Or we can just have multiple generators, now that I think about it:
So sane install sane-auth runs sane generate sane-auth which adds the basic authentication. Then we have two more sane generate sane-auth-social and sane generate sane-auth-user-roles which add their respective additional functionality. (The sane-auth namespacing would happen automatically based on the addon-name)

That actually does bring another issue up, naming and 'namespacing' of the generators. Right now only sane-addon is required in the keywords. But should we also have some conventions for generator names? For example we could actually remove the 'sane-' here, so it would just be sane g auth (as well as sane g auth-social, etc.) and you could run sane i auth and it would first look for sane-auth. But this could also cause issues in the future if we are not completely clear and strict about it.

I am also thinking here how the ember-cli ecosystem works. 90% of the addons have ember-cli in front, but some like liquid-fire do not. And we should not restrict naming at least.

What do you think?

@kriswill you had an idea about that as well I believe?

This was referenced Mar 1, 2015
@kriswill
Copy link
Contributor

kriswill commented Mar 1, 2015

As far as naming goes, I don't think it's that important. Some people will want to find things by name, but ultimately it comes down to the module possessing the correct dependency on sane-addon. Programmatically we can validate addon modules at runtime by using npm.commands.view(["[email protected]", "dependencies"], callback) see docs. I do believe that all of the modules should in-fact be node modules published to npm or private git repos. The command-line syntax should be compatible with name@version or git specification for npm.

For the sane-auth addon module, I think they can work similarly to how ember-simple-auth works, in that they simply reside at the same level as sane-auth, and aren't a hierarchy. something like:

Package.json:

{
  "devDependencies": {
    "sane-auth": "*",
    "sane-auth-social-core": "*",
    "sane-auth-social-twitter": "*",
    "sane-auth-social-facebook": "*"
  }
}

@mgenev
Copy link
Member Author

mgenev commented Mar 1, 2015

I tend to think sane- is a good prefix for sake of discovery, but it is true that the keyword serves that purpose as well as install

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants