Open carpeliam opened 11 years ago
Liam,
Having both options sounds like a great idea!
Ruth
On Tue, Jun 25, 2013 at 7:37 PM, Liam Morley notifications@github.comwrote:
In order to support user-based features (such as #7https://github.com/codeforboston/pantry_pickup/issues/7, and others), we'll need to support user authentication.
If we support authentication through facebook/google+/twitter, this will help people avoid creating yet another password, as well as make it easier for people to socialize pantry pickup with other people.
It's also worth creating the old-fashioned username/password to support people who don't like sharing their credentials with facebook/google+/twitter, or sharing their social media connections with Pantry Pickup.
— Reply to this email directly or view it on GitHubhttps://github.com/codeforboston/pantry_pickup/issues/24 .
I'm going on travel for a little while, so I'm going to unassign myself; so far, I've looked into libraries that will make this easier. It looks like passport.js might be the best way to go.
passport.js looks pretty good. Will have a go at setting local and twitter auth, and we can take it from there.
It would be easier to setup forms with something like bootstrap or foundation... any problems with that?
I generally don't love those libraries visually because they make things look boring and generic, but I do like the tools they give you, esp the gridding system. If you want to use it to get started, it's cool by me, by I'll probably sweep through at some point and restyle things.
@WheresHJ agreed. I think it has good normalization/reset defaults, and I use it on both personal projects (my own website) and at work, but the default componentry (esp. the buttons, imho) is a bit generic.
On the plus side, using something systematic like bootstrap helps push us to be consistent in our typography/margins etc, and it does make form layout pretty easy. Sounds good to me!
As far as twitter auth etc goes. The config module I added recently has support for pulling in configuration files that match the hostname. I'm thinking we don't want to be storing OAuth keys/secrets in github, I was thinking we could store those in a config file kept on the production box. Does this sound like the direction you were going in? (Using Capistrano, this would be stored in a directory apart from the releases, and the deployment procedure would create a dynamic link to this file before starting the app.. I can work this out with @ohnorobo, if that's the direction we go in.)
Hey guys, yes, I also agree, I used to hate bootstrap, then I used it, and it was a great experience... Might give Foundation a go though (or at least review it).
@carpeliam haven't thought about config yet, but will have a look at that module. I tend not to push keys up to github (when I remember!). We can do something like a sample_config with placeholders, and add the real config file in .gitignore. In any case, I'll focus on getting it working first, then we can see how to make it right... sound good?
Sounds good!
http://jedireza.github.io/drywall/ seems like a potential turn-key solution, at first glance?
seems pretty slick.
On Thu, Sep 12, 2013 at 1:21 AM, Liam Morley notifications@github.comwrote:
http://jedireza.github.io/drywall/ seems like a potential turn-key solution, at first glance?
— Reply to this email directly or view it on GitHubhttps://github.com/codeforboston/pantry_pickup/issues/24#issuecomment-24295814 .
I was just thinking about it, and it might be good to see if we can genericize the authentication stuff - esp as we go ahead with Badges, Street Cred, etc - so that other Brigade projects can use it easily. Just a thought.
It looks good! but might be a bit overkill for this particular app? will have a look over the weekend, see how easy it is to actually integrate. Passport looks more low level (more flexible, probably).
With regards to other projects, as long as they are node projects, might work.
I agree that Passport is most likely more low level, my thought is that if drywall accomplishes all or most of what we need up front and is easy to drop in, then I'm ok with adopting it for now to allow us to concentrate on other work until it stops meeting our needs. If drywall gives us a fast path to providing a demo to pantry owners, where they can log in, then that's great too.
@WheresHJ let's talk more about genericizing authentication. drywall (as well as any other approach we take) should support logging in with arbitrary criteria like Google, Facebook, Twitter, and whatever other kind of OpenID approach we want to go with.. maybe Personas too, I don't remember. Would that be enough?
Hey guys, put a quick doc together: https://docs.google.com/document/d/14_5jSsvRpITCH_jCcXDdeOYWAE1OrHOWjxnbLZJoeNo/edit?usp=sharing
(Open for comments, but I can give you edit access if you send accounts)
@josmas thanks for this. Ah, interesting, I hadn't looked into drywall enough to see whether it was a module or not... if it's an application skeleton, yeah, that changes the game a little bit.
I finally went with plain passport; PR opened for very basic auth (no user management, just login/profile/logout). #38
Didn't hook it up to the main page cause I know @carpeliam is making changes there. Can keep working on this without touching the main page, so all good.
In order to support user-based features (such as #7, and others), we'll need to support user authentication.
If we support authentication through facebook/google+/twitter, this will help people avoid creating yet another password, as well as make it easier for people to socialize pantry pickup with other people.
It's also worth creating the old-fashioned username/password to support people who don't like sharing their credentials with facebook/google+/twitter, or sharing their social media connections with Pantry Pickup.