1.0 Roadmap

[Ch4s3]

I'm starting this issue to discuss our path to a 1.0 release. Please feel free to request features here and discuss areas that need improvement or bug fixes.

• OAuth / Provider test mocking (see omniauth mocking)
  • Fake successful auth call for any provider
  • Fake unsuccessful auth call for any provider
• Token auth JWT authentication #70 probably with something like jwt
• Support usage of multiple authentications for a single user (not sure if this is already implemented)
• Support accounts without passwords (strictly external auth)
• Contribution guide
• Consider OmniAuth re External submodule architecture NoamB/sorcery#533
• Issue template
• Improve docs

ported from here

[nsantiago2719]

I think you need to review the create_from(provider) method. Because [email protected] is the same with [email protected] but in sorcery it treats it differently.

In google's view:
[email protected] == [email protected]

But in sorcery's view:
[email protected] != [email protected]

A solution can be made like the others suggest before that I can filter it through my registration controller. But I think it's a little bit different know because of the create_from(provider) method.

[Ch4s3]

@nsantiago2719 can you file an issue for this?

[joshbuker]

@nsantiago2719 @Ch4s3 Not all providers ignore periods, so treating them as separate emails makes sense for the most part. I'm of the same mindset of @jrochkind in #748 that provider specific code should probably be documented in the wiki (with examples), but left to users to implement. One of the main draws of Sorcery is that it doesn't do everything for you, and lets you handle things in a way that makes sense for your application.

[Ch4s3]

I was unaware that other providers recognize '.'

[nsantiago2719]

@athix what I am referring right now is the create_from(provider) method for external providers. That's why it's a little bit different to the issue that I opened before.

[joshbuker]

@Ch4s3 Looks like Microsoft, Yahoo, and Apple treat periods as separate emails, while Google and Facebook treat them as the same.

@nsantiago2719 Hmm. Can you open a new ticket on this repo where we can discuss it further? Including the specifics on what's not behaving the way you'd expect would be helpful. Thanks! :)

[kyuden]

@Ch4s3 @athix

How about add omniauth integration to 1.0 Roadmap?

OAuth / Provider test mocking (see omniauth mocking)
　　Fake successful auth call for any provider
　　Fake unsuccessful auth call for any provider

It may be able to remove this If omniauth integration is implemented.
Because we can use mocking of omniauth itself.

[Ch4s3]

@kyuden Reading that old thread, this makes sense.

[joshbuker]

I could definitely get behind utilizing omniauth's existing infrastructure for oauth. I think we'd want to carefully considering all the possible implications first, but it would reduce the maintenance of external providers considerably.

We also should start looking at how/if we plan on dividing sorcery up into separate modules soon. It could be that we just make the code itself more independent, or we split sorcery into multiple gems. Both have strong advantages and disadvantages.

[Ch4s3]

What is your preference re: making the code itself more independent vs. splitting @athix?

[jrochkind]

you might consider making the code more independent as a first step, then to consider splitting as a second step. Since the second requires the first as a first step anyway.

[Ch4s3]

Yeah, I think that's probably how we'd approach it. Omniauth could be a good part of that.

[joshbuker]

Going to be working towards this on my fork athix/sorcery:1-0-0

Current objectives:

• Gain better understanding of existing codebase
  • Complete rubocop TODO
  • Get code coverage to min 90% This will be done for new code going forward.
• Separate code into unit-tested modules
  • Core
  • Passwords
  • HTTP Basic Auth
  • External
  • Remember Me
  • Reset Password
  • Session Timeout
  • User Activation
  • Add module dependency (e.g. all require core, reset password requires password auth, login method requires either password auth or external auth)
• Replace External module code with omniauth integration

[joshbuker]

Would anyone object to dropping support for Rails 4? With Rails 6 on the horizon, I think it would make sense to keep the code sane.

[Ch4s3]

I think that's probably reasonable

[mladenilic]

+1 for dropping support for 4.x.

[joshbuker]

@mladenilic here's some of the old ideas for Sorcery 1.0. Might need some refreshing considering how long it's been, but hopefully it can give a head-start.

[joshbuker]

This will be continued by #248, closing.