I am trying to find a way to distribute a Ruby on Rails app selectively by sending them an email with the link that logs them in. This should be the only way to get to the page hosted at a unique subdomain. Additionally, we don't plan on having a login wall so the access would need to be guarded by using Cookies or the Query URL params.
A couple of questions regarding this:
Is it possible to leverage cookies exclusively to achieve this? I.e Any way to embed cookies within the URL sent in the email itself?
An approach I felt that might work is to embed the user ID (encrypted) in the URL in the email. In order for the users to not need to bookmark this URL or go back to the email to access this link, I was planning to store their session ID via a browser cookie. Any issues with this approach?
How to avoid wandering users(i.e users who haven't received this email) to access this page (i.e a nice way to raise a 404 error)?
Any other cleaner ways to accomplish this task?
Is it possible to leverage cookies exclusively to achieve this? I.e
Any way to embed cookies within the URL sent in the email itself?
No. You cannot "embed cookes in a URL". Cookies are set via the SET-COOKIE header in a response or through JavaScript.
An approach I felt that might work is to embed the user ID (encrypted)
in the URL in the email. In order for the users to not need to
bookmark this URL or go back to the email to access this link, I was
planning to store their session ID via a browser cookie. Any issues
with this approach?
Yes. You should generate a random token thats not tied the users id.
How to avoid wandering users(i.e users who haven't received this
email) to access this page (i.e a nice way to raise a 404 error)?
Create time limited access tokens that can only be used once by the user. There really is no other way for you to actually know that the person requesting the URL is the recipient of the email.
What you are describing can be accomplished with Devise Invitable which is a pretty good community tested point of reference if you want to reinvent the wheel.
When you invite a user Invitable creates invitation tokens which are stored in the users table. This is just a random string. There are also timestamp columns that expire invitations automatically.
The token is included in the URL in the invitation email as a query parameters.
When the user clicks the link the controller looks up the user based on the token and nulls users.invitation_token so that it cannot be used again. This stores the user id in the session and takes the user to a screen where they edit and finalize their account by setting a password.
Related
We are tracking a forgot password workflow action using adobe site catalyst. The flow happens something like below
User requests for forgot password
He provides the email address and clicks on create new password
New password generation like is send to his email address
User clicks on this link and generates a new password
First 3 actions occurs in the same browser. The 4th activity can occur in the same browser or a different browser. Because of this, site catalyst considers that user as a different one (different visitor ID) and considers that as a totally different visit. Ideally the number of users who completes activity 4 should be less than that completes 1,2,3.
But for us, we are seeing more users who completes activity 4 which could be because of this different visitor issue.
Can someone please suggest a better approach to solve this?
You might want to try overwriting the Visitor ID.
I do not know how your site works in the backend, but generally, and theoretically (as I have yet to be asked by clients on to implement this):
Extract the Visitor ID when the user provides the email address and clicks on create new password. You might want to check the appendVisitorIDsTo (Cross-Domain Tracking) function out and see how the Visitor ID query parameter is implemented.
Send the Visitor ID along with the email address to your backend controller that spits out the template forget password email.
In the template forget password email, append the extracted Visitor ID as a query parameter in the reset link.
In DTM (if you are using DTM), modify your Marketing Cloud Visitor Service tool enable this configuration: overwriteCrossDomainMCIDAndAID.
When the user clicks on this reset link, the Visitor ID should be the one that is initially created for the user.
You might want to read this answer as well.
I have an upload application that will be accessible by multiple other applications. I want user security from those applications to be federated to this upload hub. I'm doing it with HTTP tokens that are shared between the applications.
I have read 5 different articles on how to secure an API in Rails. I have everything set up properly in the upload hub app. I have keys set up in my User table, and I have shared this key with the user table in the other apps. I have the code in place to check for this key, and to locate the appropriate subscription. Upon failure, the user is redirected to the login page of the source application.
There's just one thing. I can't find anywhere how to create the actual request! I want the users in the other applications to click an "upload" link that will take them to this application. No problem creating the link, of course. The problem is, how do I add the token to the request?
See, I'm not making programmatic requests to an API... The user is actually going from one app to another. I want the upload hub app to check the request and say "Oh, there's this big long key. Let me see if I can find a user associated with that. I'm obviously not going to put it in a query string.
The only thing I've come up with on my own is to have a bit of jQuery code that constructs a form with a hidden item containing the key in it, which it would get from a hidden field on the current page, then do a POST against the upload hub app. That's not really a token, but it's doable. Surely there's a better way?
UPDATE
I went the jQuery "postGo" route where I construct a form with a hidden field and send it as a parameter to the other app. I had forgotten about protect_from_forgery though. However, even after turning protect_from_forgery off, Rails somehow still strips all parameters except for controller and action from outside requests. Undocumented feature? Or maybe I missed the documentation.
Really, I just want SSO on a couple of apps. It looks like I'm going to have to create an Oath provider. Sure are a lot of hoops to jump through to federate a simple session on some apps that I own.
Here's a possible way of doing this.
In the upload controller method of the app, instead of redirecting the user directly, make a request to the upload hub app.
In the upload hub app, add a controller method and generate a token, store it and a user's credential in redis, or other storage of your choice, then response the app with the token.
Your app's upload controller method receive the response from upload hub, then give 302 response back to the client, with the token included in the redirect url.
The client redirects to the upload hub
The upload hub router accepts this format, the token can be in a query string.
Check in redis and find it by the token and match the user's credential
I'll describe my question through my use case -- I (using the tweetstream gem) receive and process tweets on a push basis, and for some of those events, I reply to the user with a link to a signup form for my website. Currently, users have to do auth via twitter on my site before they can submit the sign up form so that I can securely verify that they own that twitter account they claim to be.
However, that is preventing a lot of conversion, so I would like to remove the login with twitter step. My thought then, was that on receiving an event, I could hash their twitter user_id with a random string I store, and add that hash (token) as a query param on the signup link. The link would autofill the token into a hidden field in the signup form, thus (I think?) allowing us to verify the user's twitter id again on form submission.
The one caveat to this is someone could use another user's signup link and appear as them, but this isn't a concern in our case because due to the nature of the signup data. Doing that maliciously wouldn't make sense, and doing it unintentionally, we can do by displaying the apparent twitter handle prominently on the form. Account access post signup will still require login with twitter so that isn't an issue either.
So my question then is, does this seem like a sound approach, and are there any rails gems that have this functionality or would be useful? (Basically a custom version of how authenticity token protection works I think) Thanks!
I think a better approach is not having a signup form and instead simply letting people login using twitter. Is there really something you need them to manually fill in on the signup forum that you can't automatically retrieve when they login with twitter?
As part of my app, users get to approve certain "requests" via email. Requests have their own model and therefore each has a unique id.
Users get an email with a named route in a link: 'approve/:id' where :id is the id of the request. The approve method then handles the approval logic, etc.
How can I prevent a user from approving requests made to other users without having the user login beforehand? Since the ids are freely displayed in the URL, I guess a GUID would be needed or?
If you really want to do that, then yes, you'd need a GUID of some sort. Perhaps a cryptographic hash of the user_id or email address(?). so you end up using /approve/:id/:GUID.
I'm surprised you don't want the user to login though, remember that if they login you can redirect them on to the approval automatically. Also if the cookie is still valid a user may already be logged in.
We have a Rails 3 app using session-based authentication (modified acts_as_authenticated), and a Flex app that needs to be embedded in an html.erb template. The Flex app needs to access routes that have a before_filter set to check if the user is logged in. When interacting with the HTML site, this causes the user to be redirected to a login page, then sets a Rails session property (tied to a cookie) to record that the user is logged in when making future requests.
The Flex app needs to access XML that's generated by Rails (behind the before_filter) and I don't want to force the user to log in twice -- what should I be passing as a flash parameter to the Flex app so that it can present as "already logged in" if that session exists (ie, the user has logged in via the HTML interface)? I haven't dealt with this kind of problem before so I'm not sure if I'm even asking the right question. Any advice appreciated!
Integrating flash into your authenticated service can be tricky. You can't rely on normal http sessions or cookies to manage authentication for you. What is generally regarded best practice is to generate a unique token for each logged in user to pass on every request to the server to prove that they are in fact a logged in user. for example:
They log in through an html form.
When you serve up a swf that is going to access authenticated content you give it a flashvar of token=49r03f0239fhduffnkdjfgnas or something like that.
This token is generated server-side and stored somewhere to be checked on requests.
On every request to the server you pass this token and check it's validity.
If it's good you perform the action and return the data.
If it's bad you prompt the user.
notes:
tokens should be long and unguessable like a session variable.
each time they log in you need to generate a new token.
each time they log out you need to destroy the token.