A rare situation has occurred in our project whereby two orders are mapped to the same guest customer in production environment. However,it is expected that every time a guest user places an order, a new user with guest id is created out of the box.
What should be the test scenario to replicate this?
A guest customer is created with a specific generated uid. This uid is generated like this:
UUID.randomUUID().toString() + "|" + email
In the very unlikely case that for a guest customer with the same email, the same UUID is generated, the customer might be retrieved from the database and assigned a second cart. However this should throw a DuplicateUidException and prevent the following code from executing.
Refer to this method for more details:
de.hybris.platform.commercefacades.customer.impl.DefaultCustomerFacade#createGuestUserForAnonymousCheckout
May be these guest user give same email address or your email unwanted character cleaning code made them same.
Related
Usually, when you sign up for an account on a website or post something to Craigslist, the website will send you an email and your account won't be active until you click the link in your email.
I know this is done to confirm that you are a person and prevent robots from spamming the site, but I don't understand what is going on server side.
Does the site save your information in a temporary database? Does the email link they send you secretly contain all the information needed to start your account?
Very curious if there are different methods for doing this and what the pros/cons are?
The server, well. It saves the user information, generates a pseudo-random string (generally a 32, 64 or even 256 byte token), which "identifies" you as you.
In the email, it sends you, it will and an anchor (and as you click it), it will recover that token and make your account active.
An example using an anchor + GET param:
http://example.com?token=acbd18db4cc2f85cedef654fccc4a4d8
md5('foo') => acbd18db4cc2f85cedef654fccc4a4d8
For the 'pseudo-random', any criteria is available, since the id your were given in the database, to some random crypto utils.
i guess the link that you get in the email contains a unique string for the new user that is not confirmed, so when you open the link the server can select which user confirmed the email.
Just thinking about my registration flow for my Nodejs/MongoDB app and wondered whether I really need to check if email addresses are already in the database when users register.
I make my users verify their email address by clicking on an email that I will send to them. They must do this before logging in at all. Once they do click on this link then I will mark that email as verified in the database. With this in mind, I'm thinking that it doesn't really matter if someone registers with the same email address (for whatever reason) as it won't be marked as verified unless they can access the email account.
I'm wondering however if it will impact on performance when it comes to searching for users in the database via email address. For example, users login using email address. Would it be advisable in this case to create an index on both email and verified?
Have I overlooked something that could potentially be a security flaw?
Performance-wise it will probably not matter a great deal (you probably already have an index on the email field), but I don't think you should allow it anyway.
For one, it has the potential to add junk to your database. Secondly, it would allow existing users to create—by mistake or not—a second account with the same e-mail address, which could cause all sorts of issues.
You don't give a specific reason for wanting to allow duplicate e-mail addresses, but a duplicate check isn't really all that time-consuming to implement (you could also consider a unique index on email so the database will throw an error when someone is trying to reregister an existing address).
In my XPages application, web users can perform a self-registration. In the registration process, a user document for the web user is created in the address book and the user is added to a group that has Editor access for the database. After executing show nlcache reset on the Domino server, the user can login to and access the application.
In ~98% of all registrations this works perfectly fine. However, sometimes new users cannot enter the application after the login because, according to the Domino server, they "are not authorized to access" the database. The login must have worked because the user id is correct. The exact same user id can also be found in the Members field of the group that has Editor access to the database. To additionally verify the user's access level, I executed NotesDatabase.queryAccess() with the user's id. It returned 0, which is the ACL default and means "No Access". Yet, there are dozens of users in the same ACL group which have absolutely no problem with accessing the database.
At the moment, we "circumvent" this problem by manually removing the user's document from the address book as well as remove him/her from the Members of the ACL group. Afterwards we ask the user the re-do the self-registration with the exact same information as before. Up to now, this second registration has always worked and the user can access the application. Yet, this is not a real solution, which is why I have to ask if anyone knows what could be the problem?
Don't create entries in the address book directly. Use the adminp process for registration. To minimize perceived delay send a validation/confirmation message the user has to click.
Comment of 12/02/2015 seems to be the correct Answer:
Check if the self-registrated user has TWO consecutives spaces in his name, (could be because trailling space too)
In group domino do a FullTrim. So we have
John<space><space>Smith
that is not in group XXX because in the members it's:
John<space>Smith.
This may have something to do with the frequency at which the views index are refreshed in the names.nsf
Since the access control is done groups in the ACL, the server will "know" which user belongs to which group only after the views index have been updated.
In a normal setting, this can take a couple of minutes.
You can test this hypothesis by forcing an index refresh, either with CTRL-MAJ-F9 from your Notes client (warning, can take very long depending on network and number of entries in the names.nsf) or with the command
load updall -v names.nsf
... or by having the users wait a little while and try again 5min later.
Ok, first a question. If you let the user wait a couple of minutes will the access then work? I.e. is it a refresh/caching problem - or an inconsistency in the way you add the user to the group?
I assume that the format of the user name is correct as it works in most cases (i.e. fully hierarchical name)... Is there anything "special" about the names that do not work?
I do a similar thing (and has done several times) - although with some differences :-)
I typically use Directory Assistance to include my database with a "($Users)" view. When I update anything in this view I do a view.refresh() on the view (using Java). I typically do not use groups in these type of applications (either not applicable - or I use OU's or roles for specific users). I am not sure how the group membership is calculated - but I guess you could try to locate the relevant view (though none of them seemed obvious when I looked) - and do a refresh on it.
/John
CouchDB offers validation prior to allowing an object/row to be inserted into the database. This make sure that if you have a public facing couch application, you're database won't be filled with junk by just anyone.
User <-> CouchDB
However, I'm tring to figure out what that looks like comming from the standard application design process where you have a trusted middle layer that does much of the auth work. For example, most apps place Ruby or PHP between the database and user agent which allows the application to figure out information about the user agent before allowing something like a post to be saved to the database.
User -> Ruby -> MySQL
User <- Ruby <- MySQL
How do you trust the user to do administrative tasks when the user can't be trusted?
For example, how would you do something like "email verification" prior to inserting a user row using just couchDB? You can't let the user agent insert the row - because they would fill the system with spam accounts. On the other hand, there is no middle layer either that can insert the row after they click the link in the email.
How about this, I would assume that you would allow anyone to enter their email by creating a new record in a public table like email_verify. This is something that a public user agent could do as the table would not do anything in the application - it would just be a holding tank.
Then node.js could track the _changes feed and send an activation email while creating a new entry in a private table (like email_confirm) (node.js would serve as a trusted middle layer). If the user clicks that link and comes back then... [unknown] ... and node.js could finally create a record in the private user table (user).
At this point we could then rely on couchdb validation for the rest of the application since we got a confirmed user account created.
As more background lets imagine a discussion built on couchdb that anyone can register for. We don't want to allow just anyone to directly submit content without some kind of verification - yet the user agents all directly run the system. (Tables would be Thread, Comment, & User). How would this work?
I would think about adding roles to existing users in this issue.
Using couchdb's validation and changing _design/_auth can be a good idea to add email, email_verified and randomly generated email_verification_code in _users database when the user firsts registers.
To send mail, get confirmation, resend confirmation you can use external processes. (for an example usage of external process you can check couchdb-lucene).
And at last you can again do a quick check in _design/_auth in user update process if verification code matches and add verified_user role for that user.
This way all your requests would pass over couchdb, you would use external process only when you need to send mail and get confirmation.
Edit : Forgot to add (since it was pretty obvious), I would add verified_user role to database readers.
Couldn't you just make use of CouchDb's Validation ?
Users could be flagged. Upon registration, a User is added to the Users database. He gets his mail and then is flagged "valid:true" or something like this upon answering to that mail or clicking a link.
With validation users could not only be "logged in/out" but also access authorization can be implemented with more granular access rights. E.g.: Only mark threads solved if one is the author, admin, whatever...
Or does this seem impracticable?
After talking with some people on #couchdb IRC, it seems that they can't figure out out a way to do something administrative (like activation users that click on a email link) with out using a "backend" process like a node.js server which keeps track of the _changes feed.
I was hoping for a pure couchdb app - but it seems like couchdb still has a little ways to go.
Still, the good news is that you can hand off 80% of your applications logic/processing to your users. The other 20% will be 1) a node.js instance for things like sending emails or checking recaptcha and 2) record validation functions running in your couchdb, and 3) map/reduce (query) functions. These three things cannot be offloaded to something "untrusted" like a user-agent.
On a standard web signup form, users are required to have a unique email for the site.
if the email is already in use, a new user cannot be created with that email - but this opens op for exploiting this to find out, what emails are members of the site (at least check if a specific email is in use).
Making sure a bot cannot mass-query is fairly straightforward - but is there a way to avoid it entirely?
The best thing I can come up with is letting the user create process fail with an unknown error and shooting an email to the address in the background, explaining password reset procedures.
Am I missing a better option?
Update:
I want to avoid taking the new user out of the registration process for the 99.9% of the time, when the email is actually unique. So halting the registration process to wait for the user to click a link in an email is not a perfect solution, although maybe viable in some use cases.
Let the registration continue as normal, but in the confirmation email you should say:
"You allready have an accout bla, click here to cancel this registration, or continue with new registration and delete your current account"
That way, the spammers never know the better, and its very user friendly.
You could print on the web-page something along this:
An email is sent to you to verify the email address. Check your mail and click the included (shared-secret) link.
I.e. you probably have to verify the users email anyway, s.t. you can do it at this location of dialog ...
Many sites send a mail to the specified email address containing a randomly generated verification code and only accept the user registration once the user has confirmed they were able to read that mail and obtain the verification code. Usually the mail contains an URL that the user can simply click to confirm.
If you do that, all you need to do is make the confirmation email instead tell the user that they've already registered and explain the password reset procedure.
Whatever web development framework probably has a package that handles confirmation mails.
Note that you have to think about the case where a user had an email address and used it to register to your site, then they vanished without changing the address and stopped using the address, and another user now has the address and wants to register. There's no easy answer here.
ADDED: You add that you don't want a confirmation email so that the registration proceeds immediately. This requirement is contradictory with unique email addresses, because you don't know that the email address supplied by the user is legitimate until it's been confirmed, and there's no point in enforcing the uniqueness of a user-chosen string that just happens to be formatted like an email address (if you want a unique user name, it doesn't need to be formatted like an email address).
If you want to keep instant registration, you'll have to treat email addresses as just an untrusted text field until confirmed. That means that every action that requires your site to send a mail must bomb out if the user hasn't confirm his email address. The confirmation process remains pretty much the same, but now, if the address is a duplicate, the user must either be given the option to merge the two accounts (which sound difficult), or told that he must close one of the two accounts or change the email address associated with one of the two accounts.