I would like to add referral program to my website. The user is taken from some other page to my homepage with referral url parameter like:
www.example.com?referral=refCode
The thing is, the only time I care about the referral code is at the signup page.
www.example.com/signup
Is there a way to retain the referral code through user journey on my website?
I solved the issue using cookies. Spring Boot provides easy access to cookie operations as described for example in this article.
When an user reaches my home page, I check for the referral parameter and if it exists, I store it in the cookie. I set cookie expiry date for 14 days for example. In the POST controller for the sign-up, I check their cookie and if it contains the referral info, I store it in the DB for the user.
Related
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.
I have a website where users can create an account and log in. This is stored in a database on the server. I also want users to be able to log in with Facebook etc, and thus skip the account creation. I don't know how to combine this and keep it persistent in the database. Any good examples on this use case?
Let's first see how logins work in general. When a user is logging in for the first time, a session id is generated for the user and is stored in the browser of the user as a cookie (note that there are mechanisms to store session id without a cookie, but let's assume you require a cookie for simplicity).
For subsequent requests to other pages in the same website, the cookie is also sent along. With this cookie (which has the session id), the unique user can be identified.
So, all that you require to know to identify a user in the server side (upon a web request) is the session id.
Having said that, if you want to include facebook etc into the login mechanisms, you need to do two things:
Connect your website with facebook (you will require a facebook developer account and some keys. Look here). When you do this successfully, if the user selects facebook login, your website should redirect to facebook login page and once the user logs in into facebook account, facebook will redirect back to your website with a token. This token is an indication that the user is a 'real' user. If required, you can use the token to get more details (such as facebook id, email address, name, etc.) from APIs facebook.
The second step is the same for any authentication flow. You need to generate a session id for use by your server and then save the session id in cookie.
What I have specified is the general flow on how your requirement could be achieved. The mechanics of how to do this will depend on the server side technology that you are adopting (such as ASP.NET, Ruby, etc.)
Additionally, if your website requires storing information about the user behavior / user activity, you may need to additionally check if the user logged in via FB already exists in your database. If not present, you can store the user's facebook id or something to uniquely identify the user later. With this as the primary key / user id, you can store user activity (such as inserting a record in orders table if the user purchases a product).
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.
How is the server-side flow supposed to be for Facebook Apps? What I mean is, on every page load, do I have to get an access token?
Currently, in my application_controller, I have a before filter that basically
redirect_to #fb_auth.client.web_server.authorize_url (authorizes the app)
#fb_auth.client.web_server.get_access_token (gets the access token)
This seems really slow to have to get another access_token from Facebook on every page load. How is this normally done? The problem that I'm having is that to access the /me object you have to get an access token, which requires me to get the access token on every page load.
You shouldn't need to get a new access token on every page load. The access token should be good for many page loads as it takes over an hour to expire (expiration info is available when you get the token).
Also you don't have to redirect every time. On POSTs to your app (such as when the user clicks over to your app) a signed_request is included with the post data. If the user has not authorized your app, that's the time to redirect to the fb_auth. If the user has previously authorized your app, an access_token should be in the signed_request.
More info here:
http://developers.facebook.com/docs/samples/canvas/
there is a sample skeleton application available # https://github.com/michaelbaldry/fb_graph_canvas
access_token is gained when a person first visits the canvas url on apps.facebook.com/appname/ once this has happened the access_token is stored in a table and used until the next time the user comes straight to the canvas url.
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.