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.
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.
At our company, we are working with several aliases. The current situation is that one team of 10 has two aliases. In SalesForce, they would like to put the link to specific emails so that anybody out of the team can open an e-mail related to a claim for instance.
In the e-mail's link, there's the "/u/0" part that identifies the mail gmail account (firstname.lastname#...), but it seems that the aliases have a different number for everybody.
So to be clear when they open the same mail in the shared alias, the e-mail ID stays the same in the URL (logic) but the digit after the "/u/" changes for everybody.
Is there a way to generate a URL that will open the e-mail independently of the person that clicks on the URL ?
Edit:
I'll try to be clearer. Our Customer Service Center employees all have two e-mail adresses: an individual one, and a delegated one. Customers will send e-mails to the delegated one (accessible by all employees). So what we would like to do is copy the link of the e-mail into SalesForce so that any employee (who has access to the delegated gmail) can check the e-mail. But, as explained above, as the individual gmail adress is always identified by a "0" after the "/u/" chain in the URL:
https://mail.google.com/mail/u/0/#inbox/156b821f776b6d4a
the delegated gmail adress is identified by a number that differs depending on the person. So employee A will have "/u/144/" as link to the delegated gmail, another employee will have "u/345/ as link to the delegated gmail. This makes it impossible to access the e-mail by clicking the link...
Hope this little case-study makes the issue clearer.
Thanks in advance
Julien
I'm trying to do this too.
I think the only way (outside of paying for the Google business email system) is to have a database of user IDs that link to each user's gmail delegate URL.
I have a system that allows about 6 or 7 users to login, however they all share the login details (it's a small website, with no important information stored). I will have to force them all to have separate login details, and then have a lookup for their gmail delegate URL.
If you have a lot of staff, then you'd have to get their buy-in. Maybe send a global email around that links to a simple web form, that takes them through how to enter their delegate URL. Then store this in a database, with their own personal email (the other gmail account). You should make the form validation strict, so no garbage gets entered. For users who get stuck (fail validation for entering a valid gmail delegate URL), ask them to email support. 95% of staff should be able to handle this. The other 5% would just be an exercise in patience, in getting the rest of the data.
I'm writing an ASP.NET MVC application, which uses the Membership database to store user registrations. I use email addresses as usernames. When a user registers in my app, I send out an email-confirmation to the address they have used during registration. i.e. I send out an email with a link, which the user is supposed to click, to verify that the address belongs to him.
Until that link is clicked, the account remains 'Unconfirmed' (i.e. EmailConfirmed column equals False). Which means, the account is created, just not active.
How do I deal with a hacker who brute-force creates accounts? I see two big problems here:
Ever-increasing size of the Membership database. A single user, from
a single computer is not a threat, but what if he has 'zombie'
computers?
If User1 creates account with User2#example.com email and
User2 ignores the activation email, the account will essentially
remain locked (unconfirmed), but existing. If User2 decides later to
actually create an account, they can't use their email to register
(account already exists) and they can't Reset Password either -
because even if they reset the password, that does not necessarily
Activate the account.
As for 2) I see a couple of options:
Set expiration date on unconfirmed accounts - i.e. allow the username/email to be claimed again, if the email is not confirmed with 24hrs
Modify my Reset Password method to also activate the account, if it has not been activated. Is that a good idea? I mean, the person would receive an email for that, which is essentially a confirmation, if they click the reset password link in it.
Anything else?
What about 1)? How do I protect myself against bulk create of accounts? Aside from limiting 1 account per IP, per day, using code.
One simple way to deal with this kind of problem is crude but effective.
I usually add an additional field to the form that doesn't form part of what I need - but has a legitmate sounding name like 'Company' - and then I hide it from screen view using CSS. Real user's will never see this on screen, but a bot crawling through the HTML will find it.
Then, when the form is submitted, first I check to see if that form field has a value. If it has - I stop the page from executing any further or just return an HTTP Error as in 99.9% of times only a bot would have filled out that field - not a real user.
//anti-bot measure
if (!String.IsNullOrEmpty(Company.Text))
{
HttpContext.Current.Response.StatusCode = 400;
HttpContext.Current.Response.Status = "400 Bad Request";
HttpContext.Current.Response.End();
}
//carry on processing the form...
I've been using this technique on forms for several years and it's been extremely effective!
I am trying to create a sort of recall system where an admin sends a message to the entire user base via email after which all users have to confirm the message by navigating a link in the email (Confirmation token) and retyping the message in. The would a submit button on the page which will check if messages match then clears a confirmation flag in the database. I am stuck on where to even begin here. I am not worried about comparison logic in the controller. I am confused about how to generate the confirmation tokens, sending them, then redirecting users to a page for confirmation. At the moment I am use Devise with Active Admin but I am open any other gem suggestions. If any of you could give me a link to a similar tutorial or problem that would be great! Yes I have done research before asking but it most results had little relevance.
U could do this with devise
I'll share what was recently done by me, which is almost similar to your Q.
I did not use Confirmation link or any token.
Only Admin can create user.
On creation of a user, an email is sent along with id and password.
Upon user login for first time, redirect him to edit account for only password change.
Note: U can use friendly token for generating random password.
This is probably a repeat. However, the other answers haven't helped me out. So, here goes.
I'm working on an application and we with need to add 'users' to it. We'll be giving the option for people to sign in with Facebook, Twitter and LinkedIn. I've worked with these APIs before, however never combined them globally.
How can I maintain and manage these users that will use different services to log in. I'm confused as to how they would be stored in a database, would I need to have a different table for each different social service or is there a way to implement a table that will house all users in one place.
From what I understand, you're asking how to manage, store, verify users that will be logging in your application through different social services.
This is how we've implemented it through the various projects we've worked with. From the list of services you've provided we've worked only with twitter and facebook, so I can only speak about that.
Setup:
We have a web service that our iOS app communicates with such as when the iOS app needs to make a request call for user login the server would take the user details trying to login and gives back a response where the app would then do whats necessary.
We have a database stored on the server with a users table which is used to verify a user.
That being said, you need to understand whats common between most social services, or to at least know what the property is that is used by these social services to uniquely identify its users. In this case they all use email to identify users.
You'll find that when interfacing your app with these different APIs, they like to use a login session key used for unique logged in sessions.
So on your database you would store whatever details you want to save of the user, but know that you need to store atleast the username, password (encrypted), email (for identification, unique column), and login_session_key.
Just double check that linkedIn does have something like a session key that it creates when a user logs in with that method. Facebook and twitter do. Send at least the 4 main data properties needed (username, password, email, session) to the server You then follow this sort of approach:
New user
If the user that is new tries to login, the server first checks the email provided even exists in the database, if it does not then you sent a response back alerting the user that the user does not exist; your app would then take them to the register screen for example.
If the user is in the registry page, save all the details you want to store of theirs including username, password and email.
Members
If the user logs in the email will exist on the server side, its an existing user so just update the session key that was sent from the app on log in if the password matches, (in some apps these session keys are used through the life cycle of the application being used, with each request sending the same session key and if at any point the session key does not match during app interaction, it can be concluded that the user has logged elsewhere on another device perhaps.
if the password does not matches return the appropriate message.
That's about it really. We're able to store all facebook and twitter users in one table.