Devise authentication for OpenID

[patrickm]

Hello,

I saw an open issue for using openid with FFC here:
https://github.com/fatfreecrm/fat_free_crm/issues/108 - and there is a
small discussion whether devise should be introduced for this.

Since it's a good opportunity to get a better understanding of both
devise and FFC, I started work to setup devise authentication for FFC
https://github.com/mulderp/fat_free_crm/tree/devise

So far, I have the login with FFC views working, and started fixing
the specs now. Currently, I am still having some issues around the
users_controller since devise has naturally some impact there
(password reset, rendering user data for other users).

It would be great to hear your feedback, or eventually interest in
collaboration on this. I guess, once devise is working, using openid
should be only a small step. What would be needed more eventually, is
a rake task to migrate authlog user based passwords into devise based
passwords (have not yet looked into it, maybe devise can 'read'
authlogic sha's too)

Thanks for your interest.

best,

patrick

[ben tillman]

Hi Patrick,

Good point about the password migration. I think devise would by
default need to use the same sha, otherwise current accounts would
have no way to authorize. Thanks for looking into this.

> --
> You received this message because you are subscribed to the Google Groups "Fat Free CRM Developers" group.
> To post to this group, send email to fat-free...@googlegroups.com.
> To unsubscribe from this group, send email to fat-free-crm-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/fat-free-crm-dev?hl=en.
>

[Steve Kenworthy]

Ben has also been working on a 'cancan' branch for ffcrm with a view to strengthen group permissions and flexibility.

As these branches affect similar parts of the system, it would be good to make sure they work nicely together.

Take a look at  https://github.com/fatfreecrm/fat_free_crm/tree/cancan 

FFCRM + devise + cancan would be a very appealing setup.

Thanks to you both.

Steve

[Patrick Mulder]

Thanks for the pointer.
From quickly looking over the commits, I see no conflicting changes
with the devise branch.
The main difference I can see, is that Devise is more related to some
kind of refactoring (AuthenticationController --> SessionsController)
and (UsersController --> RegistrationsController)
The next step, using OpenId, would indeed be related to a new feature.

So far, I am still missing the password reset part in my feature, and
eventually, how to have the re-login after a session time-out. And, as
Devise uses different columns for storing password and salt, I would
need to look how to migrate old authlogic passwords to new ones too.

Thanks for your positive resonance on this.

Cheers,

Patrick

[Patrick Mulder]

Hi Steve, Ben,

I had a talk this afternoon with a fellow Rails developer, and we
discussed the 'scoping' of resources in a REST style.
And I thought that there comes a nice supplement or add-on that comes
with devise, namely routes likes this:

http://crm.mycompany.com/europe/campaigns

with 'europe' being the scope of a group.

How this can be done with devise is for example shown here:
http://stackoverflow.com/questions/4514533/drawing-routes-using-user-name-in-rails-3-w-devise

As I am thinking to do some test with devise and the cancan branch,
what types of groups were you thinking of using? What groups would be
added in the demo data? Are the groups roles based, location based or
job based for example?

thanks and best regards,

patrick

On Mon, May 7, 2012 at 11:12 AM, Steve Kenworthy <stev...@gmail.com> wrote:

[Steve Kenworthy]

Hi Patrick.

This sounds very promising.

My suggestion would be that we make the groups as flexible as possible. The plan of the cancan branch is to provide the ability to FFCRM to know about groups but for the actual implementation of groups (whether they are location based or job based) to be left to the person who is customising ffcrm for their own usage.

Perhaps, you could make devise do a similar thing... provide the framework but leave the details to the user. And then perhaps provide a plugin that shows how one might leverage the framework to turn the features into a 'jobs' based setup or a 'location' based one (hopefully with just a few lines of code).

How does that sound?

Ben would have more understanding of this topic, so I'll defer to him as he has been doing the actual work.

Regards,

Steve

[ben tillman]

Did I hear my name?

Yes the cancan branch implements group permissions, but is still
failing specs I really need to go in and fix them but have been busy
on another project. If someone would like to volunteer for a spec
fixing session feel free :)

[Patrick Mulder]

On Thu, May 10, 2012 at 5:32 AM, ben tillman <ben.t...@gmail.com> wrote:
> Yes the cancan branch implements group permissions, but is still
> failing specs I really need to go in and fix them but have been busy
> on another project. If someone would like to volunteer for a spec
> fixing session feel free :)

Hi Ben!

I had a bit of time this morning to fix some specs related to the
missing partial permission spec. If I am right, the main issues are
around the view specs, the rest looks good. As I was working from a
Starbucks without web access, I am going to push my commits this
evening after work.

BR,

Patrick

[ben tillman]

Hi Patrick,

Thanks a lot for that. Looking forward to your pull request :)

[Patrick Mulder]

Hi Ben,

hm.. Github also included the commits with respect to synching the
cancan branch to master. Not sure, if that's the right process for
submitting a pull request.
The commit with the fixes for the view specs is actually:
https://github.com/mulderp/fat_free_crm/commit/7beceb65cfce021b9e8b752f56828165738ba6fb

This commit is included in my pull request:
https://github.com/fatfreecrm/fat_free_crm/pull/150

But I am still observing the common practices for doing this (synching
a feature branch with master, take a clean branch, and re-submit the
pull-request, etc. the mysteries of git rebase... ;-) )

Well, hope this is helpful so far.

Thanks, and br,

Patrick

[Patrick Mulder]

On Thu, May 10, 2012 at 4:23 AM, Steve Kenworthy <stev...@gmail.com> wrote:
>
> Perhaps, you could make devise do a similar thing... provide the framework
> but leave the details to the user. And then perhaps provide a plugin that
> shows how one might leverage the framework to turn the features into a
> 'jobs' based setup or a 'location' based one (hopefully with just a few
> lines of code).
>

Just a small update regarding my experiments with Devise. I encounter
a bit of problems when trying to migrate Authlogic user authentication
to Devise based authentication. Devise authentication can be used for
_new_ FFCRM installations without problems, but in my view, without
asking users to re-enter a new password, backwards compatibility of
passwords is an open discussion.

However, there are some inspiring discussions for the Spree framework,
that show some interesting authentication themes:

* http://spreecommerce.com/blog/2012/05/31/custom-authentication/
* http://spreecommerce.com/blog/2010/12/21/devise-authentication/

So, eventually, Devise is a nice option to keep in the back of the head.

Cheers,
Patrick

[Steve Kenworthy]

Hi Patrick,

I think it is possible to switch devise authentication into authlogic_sha512 mode. This means you can use devise but maintain the old encrypted passwords. (they've just refactored this out into a devise-encryptable gem)

For new installations, it would be good to offer the default devise authentication strategy (I don't know what that is), but we could have a config.yml setting to tell devise to use authlogic_sha512 for backwards compatibility.

References:

• https://groups.google.com/forum/?fromgroups#!topic/plataformatec-devise/WfBlL-KZUGo
• https://github.com/plataformatec/devise-encryptable
• http://blog.plataformatec.com.br/2012/05/say-hi-to-devise-2-1-0/

Regards,

Steve

Patrick

[Patrick Mulder]

On Thu, Jun 7, 2012 at 4:31 AM, Steve Kenworthy <stev...@gmail.com> wrote:
> Hi Patrick,
>
> I think it is possible to switch devise authentication into authlogic_sha512
> mode. This means you can use devise but maintain the old encrypted
> passwords. (they've just refactored this out into a devise-encryptable gem)
>
> For new installations, it would be good to offer the default devise
> authentication strategy (I don't know what that is), but we could have a
> config.yml setting to tell devise to use authlogic_sha512 for backwards
> compatibility.
>
> References:
>
> https://groups.google.com/forum/?fromgroups#!topic/plataformatec-devise/WfBlL-KZUGo
> https://github.com/plataformatec/devise-encryptable
> http://blog.plataformatec.com.br/2012/05/say-hi-to-devise-2-1-0/

Hi Steve,

indeed, it's not so difficult to make this working:

https://github.com/mulderp/fat_free_crm/commit/3e098e68532253e074cd934da0263ddc2b12e6ca

I see if I can make some more progress with the rest.

Cheers,

Patrick

[Steve Kenworthy]

Great! I've also just started focussing more on the cancan branch. I'm keen to get the permissions sorted out soon and into master.

If anyone else is interested in testing and fixing some, please checkout the branch and play with it. I'll keep pushing my changes regularly.

Steve

Cheers,

Patrick

[Patrick Mulder]

Ok, great! I might to clean my devise branch, since it got a bit out of synch with master. I'll watch the CanCan branch too. Update soon.

[Steve Kenworthy]

I completed the 'cancan' branch implementation this week and would be keen for others to try it out... it still uses the underlying Permission table and hence should be a seemless migration from instances running fat_free_crm master.

• There is a new admin "groups" tab that enables new groups to be created/deleted and users can be joined to those groups.
• On the 'users' tab, you can also add a user to multiple groups.
• Users and groups can be set in the 'shared' permissions section of any entity
• Also handles special 'shared' permissions, such as "copy permissions from Campaign", when converting a lead
• Some new steak tests for the admin groups tab
• New permissions_spec.rb for testing the permission logic that gets added when a class 'uses_user_permissions'

Thanks to bstillman for doing a large proportion of this work a while ago. It's good to have it in a place where we're almost ready to push to master.

Would appreciate feedback and any bug fixes so we can get this into master soon.

Regards,

Steve

[Patrick Mulder]

On Sat, Jul 7, 2012 at 11:52 AM, Steve Kenworthy <stev...@gmail.com> wrote:

> There is a new admin "groups" tab that enables new groups to be
> created/deleted and users can be joined to those groups.
> On the 'users' tab, you can also add a user to multiple groups.
> Users and groups can be set in the 'shared' permissions section of any
> entity
> Also handles special 'shared' permissions, such as "copy permissions from
> Campaign", when converting a lead
> Some new steak tests for the admin groups tab
> New permissions_spec.rb for testing the permission logic that gets added
> when a class 'uses_user_permissions'
>
> Thanks to bstillman for doing a large proportion of this work a while ago.
> It's good to have it in a place where we're almost ready to push to master.
>
> Would appreciate feedback and any bug fixes so we can get this into master
> soon.
>

It looks great so far.

Eventually, I don't see the groups tab enabled by default. Should we
use something like this in settings.yml:

{ :active : false, :text : :admin_tab_groups, :url : { :controller
: "admin/groups" } },

?

[Steve Kenworthy]

Yep, take a look at - https://github.com/fatfreecrm/fat_free_crm/blob/cancan/config/settings.default.yml#L224

It's basically added there but of course, with the current settings architecture, you have to turn it on to see it.

That's another thing I'd love to get to soon... not sure if I will though.

Glad you've had no problems... I'll be doing final testing this week, including migrations from current ffcrm instances to confirm things don't break.

steve

?

[Steve Kenworthy]

I'm at the point where my testing is almost complete and I'd like to introduce this into fat_free_crm master.

Since Ben already introduced cancan to master a few months ago, this final merge is mainly about turning on the groups functionality.

Any objections, speak up, otherwise I'll merge early next week and close down the cancan branch.

Regards,

steve

[Steve Kenworthy]

Hi all,

We hit a major milestone today when we introduced the 'cancan' branch into fat_free_crm master.

This means that groups can now be created in the admin interface and then used to 'share' contacts, opportunities, accounts etc. It also means that the permissions refactoring that has been underway for a while has now been completed.

To see the admin groups tab so you can create groups and add users to them, you'll need to update your settings.yml file to ensure that groups are in the admin tab. See config/settings.default.yml line 225.

We've tested this pretty hard on the 'cancan' branch before bringing the feature into master, but as this is a feature that touches on many core parts of the system, please be vigilant and quickly flag any issues that arise so that we can address them. I will endeavour to respond quickly as issues arise.

It's an exciting moment as it provides us with a much more flexible permissions system that will lend itself to all sorts of  innovative solutions as they arise. See app/models/users/ability.rb for where the permissions are currently defined. The possibilities are limitless as to what could effectively go here e.g. permissions based on a particular tag or inherited from a related model... such as being given permission to view contacts that belong to an account you already have permissions for... and so on...

Thanks to all those who had a part in this feature. In particular, Ben Tillman (warp) who wrote the core sections of this feature.

Regards,

Steve Kenworthy