I'm using the Authlogic Facebook Connect plugin on my site. After a bit of a struggle I can sign in with FBConnect, I can get stuff from the FBSession, like the users name, and I can logout. But, the README on the plugin site seems to suggest that following the five steps will result in the FB UID being saved in your local database (presumably against a user it will have created), but there's nothing in the docs or code that indicates how this will actually happen. What I want is that when a user signs in using FBConnect, I either match or create a new user for them. From then on I can use current_user in my controllers and views as normal (so that current_user.id is their local id, not their facebook id, since I want multiple forms of authentication), but if I want facebook stuff for that user I can access it easily, maybe with something like current_user.fb_user.
Has anyone been able to do this? If so, how?
Thanks.
This is precisely what Authlogic is suppose to do! One thing that was missing from the doc when I installed the facebook plugin was the need to add a facebook_session_key column in the users table :
add_column :users, :facebook_session_key, :string
Did you add this column?
Related
I've been asked to implement 2FA with email codes, like you get from Steam (and many banks), after you haven't logged in for awhile. I initially thought this would have been a flag I could turn on in the Devise config, but I can't find ANY place on the internet that talks about something like this. The desired process would be to generate and email a one-time pad to enter into a confirmation screen. Every reference I've found to 2FA with Devise refers to using things like SMS or an authenticator app.
Working within the framework of Devise, it seems like this might possibly boil down to unconfirming the user every so often, maybe like every other day. That way, the next time they log in, they get another email with a new link to "re-"confirm the login. The best I can find is Warden::Manager.after_authentication to set user.confirmed_at = nil, but this doesn't seem to be doing what I want.
Thanks to a friendly person on Github, I was directed to the Devise plugin, https://github.com/Houdini/two_factor_authentication, which does exactly what I wanted. I knew someone had to have already written it!
I am coming to the end of my rails project now and I have done everything I wish to do apart from confirm the users account through email before creating it. I already have it to send an email to the user but I want the user to contain a link. It's far too late to add devise now as I already have a users table etc.
I have heard of having a confirmed field in the users table and having it set to false and then true on user confirmation, but I have no idea on how to implement this. Any ideas?
If anyone else has some other solutions or links to tutorials showing how to add such feature then that would be outstanding. The end is so close yet so far.
It's never too late to add devise. If I were you, I'd do exactly this.
But, if I were to implement confirmation functionality myself, this is how I would go about this:
For each user, make a hash (as in MD5 hash). There are many ways: 1) for each user generate its own and store in a dedicated table column; 2) make one out of password salt, user id and (optionally) some static strings; 3) something else.
Send a user an email with a link, which contains his id and that hash.
When someone hits your confirmation url, you extract user id and hash from query string, and compare them with what you have. If they match, then you mark user as confirmed.
i have something in mind, i have some user types, Building owner, building manager.
I want to create user as building manager, but i dont want they have access to login system. this user are only for some selectbox in my website, but i need to show them in my user index page.
what i think i can do is create normal user and with a before_save i create a new data in another table.
In a request i need to be able to setup in my building form more than one building manager. maybe the best are with nested form.. I think i will need to add building id to my user table. maybe they can be assigned more than one building.
for now, my db structure are like this :
table users with user data (username, password, email, first and last name, phone)
table usertype have userid, typename and accesslvl
But this problem give me some managing problem. They will not be associated with user data.
How can i resolve this? Does Device can block some user? I searched in the Devise docs, but nothing found.
Thanks for your help.
There is an approach where admin users can approve other user accounts for login. You could use a similar approach but programmatically approve the accounts you actually want to allow logins for. Details are here:
https://github.com/plataformatec/devise/wiki/How-To:-Require-admin-to-activate-account-before-sign_in
I'm trying to implement a delayed-signup (aka delayed authentication aka gradual engagement) website flow using Devise + Rails.
By gradual engagement, I mean
"Don't make the user sign in until she
absolutely has to, but let her play
around and be remembered on the site"
I'm looking for a simple way to do this using devise. I feel like this is something many others have had to do, but I haven't found documentation on it.
The following approach sounds ok in my head, so I'm going to start with it:
Create users that are only "rememberable"
When certain pages are accessed, require that these users have more
data on them, like a username and
password, via something like
"before_filter :authenticate_user!" in
the appropriate controllers.
Does this approach make sense? Is there a better one? Do you have an implementation of a gradual engagement approach to signup/registration forms using Devise + Rails that you're willing to share?
I think the point of the article you gave us is to say:
only ask for sign up if necessary.
What does this mean?
Let's take an example. You're an e-commerce web site.
When does the customer has to sign up "at last"? During checkout. Never before. So you don't have to store, or remember anything about the user. Devise is never, never used here.
How do you manage the shopping cart of an unsigned in/up user? I'd say database, with session Id as primary key. Or You could store all the items ids in cookie, for later use.
In your code, if you have an action called checkout, just set in your controller a before_filter authenticate_user!, :only => [:checkout]
But maybe you have some constraints, like being able to keep your user's nickname without signing him up for example?
One alternate option is to do email-only signup, then send an email with a special link to finish registration later / bring them back to their account. There's an actively maintained tutorial on devise email-only signup at:
https://github.com/plataformatec/devise/wiki/How-To:-Email-only-sign-up
I've used this tutorial for a site I did a while back where we only asked for their email address to sign up, then later sent emails for them to complete registration / add a password.
You can keep all unsigned user's data in cookies, and transfer them to database once the user logs in, if you need to.
What would be the best way to go about giving users the ability to share a private link that enables anyone who clicks it to view a certain page/document/item that have privacy restrictions in place?
In my case:
A User creates events which are limited to certain groups of relationships in the database (namely: friends, friends of friends, etc.) I have a :before_filter in the event controller that checks the eligibility of the current logged in user to make sure that that user has permission to see the event. If they don't they get booted to the root page with an error message.
However, I want a special scenario to exist where a user can create an event with those same privacy settings and IN ADDITION, be able to share a special link with his or her friends via e-mail, facebook, etc. Those users do NOT need an account (but will need to make one in order to sign up for the event). This is important because there is also a :before_filter in the application_controller which makes sure a user is logged in.
I'm thinking there is something I could do with routing here... Right now I just have the simple /events/72 setup. Should each event have two different links: a normal one, and a "special code" version which enables them to bypass those two :before_filter?
What are people's thoughts?
I agree with David Lyod's answer (separating this concern in a different controller).
But for creating the hash I strongly recommend you salting the hash with some secret phrase.
require "digest"
Digest::SHA512.hexdigest("#{created_at}#{user_id}.mysupersonicsecretSALT")
Doing this it is not possible, without the knowlegde of the secret phrase, to calculate the hashes and test them against your system until it hits an existing one.
If you're handling sensitive data you should not be lazy.
Cheers,
Lukas
I would have a separate controller that uses a hash value to reference the event.
Something simple like the created_at + user_id hashed to create a unique reference.
You could also simply skip the check on a certain action but I would much prefer the first solution .