I need to find out if a customer (during checkout) is also currently logged in as a Zen Cart administrator. The purpose is for allowing certain actions to be available for an administrator placing an order on behalf of a customer (say, by telephone).
My first idea was to check $_SESSION['admin_id'].
However this does not seem to be set, instead $_SESSION['customer_id'] is.
I think this is because different session names are chosen in the admin and customer areas (zenAdminId vs zenid).
How can I find out if this customer would be logged in as an admin, had they been in the admin area at the same time?
I am working on the checkout step prior to sending off to a hosted payment service provider.
Edit: the merchant is logged in as an admin and is entering the customer's details, which are different to those of the admin account, into the checkout screens. It is a customer-not-present/MOTO setup.
You are correct - $_SESSION['customer_id'] is set. And there's nothing in the customer's table which indicates if this person is an admin. However, if they use the same email address for their customer account and for their admin account, you can look up their email in the customers table with $_SESSION['customer_id'], then match that against the admin_email field in the emails in Use this to look up table "admin."
It is worth noting that if your admin cookie isn't restricted by path SESSION_USE_ROOT_COOKIE_PATH=True that you can simply check for the cookie zenAdminID. You can read the contents of this cookie by querying zen_sessions, the sesskey being the value in zenAdminID.
You have to base64_decode the value from the result to get the session. It gives a serialised object, although unfortunately you are unable to use unserialize on it. You can load it as the current $_SESSION but this would overwrite your current one.
I simply did this to get the admin_id:
preg_match('/admin_id\|s:1:"([0-9]+?)"/', $admin_session, $admin_matches);
$admin_matches[1] giving the admin id value.
Related
I would like to use Stitch to sign up users. Each user must have a unqiue email and a unique user-name.
This is important for applications like chats or forums, where users should not be forced to reveal their email when communicating.
I already implemented login with email and password as described here: https://docs.mongodb.com/stitch/authentication/userpass/#authenticate-a-user
The problem is:
How to securely save a user-name on signup? I could store a users desired name in a collection and merge it into his custom user data after initial login. In order to do that, I would need to grant the user write privileges to whichever collection holds pending names. This is unsafe, since he could now change the name after the fact or even change other peoples names while they are pending.
The user needs to choose his name at the time of signup. At this time the user is still logged in via anonymous credentials. Hence, I can not restrict users to changing only their own data since they are at this point sill anonymous. I see no way of linking a users data to his future account at the time of signup. Any idea to change that?
It would seem strange, if stitch lacked the functionalities to easily sign up users with a unique name/handle in addition to email address.
I haven't used your exact software but in general I would approach the problem as follows:
When someone starts using the application anonymously, create a user object. The user at this point does not have a reserved (i.e. globally unique) user name, or email address, etc. But the user still has an internal identifier.
Associate user-visible state with the user object. This could be done through server-side sessions or signed cookies. (Unlike unsigned cookies, cryptographically signed cookies permit server to store what would otherwise have to be stored in the server-side session in a cookie, and trust that the client hasn't tampered with the information by e.g. changing the user id).
When user registers, set the user name, email address, etc. on the existing user object. User id remains the same and allows the user to continue to have access to their anonymously-generated data.
Have a process for deleting anonymous users that don't register after some time.
I'm building a website with a login and registration system where the users' information will be stored on a database. I'm implementing a standard e-mail verification step after the account creation. The process is the following: An account is created, but has a 'verified' flag set to False. Then, an e-mail is sent to the user with a link to verify the account. Finally, after the user clicks the link, the 'verified' flag is set to True.
This should be sufficient, but it got me thinking. What happens to the unverified accounts? Someone could set up millions of unverified accounts that fill up my database storage space and available usernames. This could be problematic.
Is there a way to build a similar system in which the account would only be stored in the database AFTER the verification?
One way to solve your "Problem" would be to use a Capchta at the registration and/or to delete all not-activated accounts when the registration date is further ago than x days.
You could encrypt all information of the registration in the verification link, instead of storing that information in a new user account.
When the user clicks the registration link, you would decrypt that information and create the account.
To keep the verification URL as short as possible, this would require to minimize the amount of information you request during registration. I would suggest to ask for the E-Mail only and to request all the other attributes on the verification page.
My question is almost the same as this one
only difference is that users has an option to register (provides his username and password).Users should only have one account registered, if the user has the same email I merged those accounts. and my application has another method for logging in which is via Facebook.
What I basically do is
When The User visits the for site for the first time, he or she then
gets created a User Account where the it only has Username ,password
and mail address after that third-party identity record is created
and then paired with the local account.however the Users table will
have an empty Username and password, but the email will be filled
with the users email that we have retrieved from the third party
service provider
And the Second Scenario
Users attempts Register to the site. check if email exist if the
email exist but it is registered using a third party account, Use
the user populated form and insert it to the user account paired
with the third party account, in short if the users email exist in the database I
will just merged the locally created account and the third party
account.
Now my question is my approach secure and credible? if not what is the best way to merge accounts and at the same time if the user registers with the same email(the one from the third party account) and he has a third party account, those account would be merge?
The way I look at this, there is only one account. One email, one account period. There might be various attributes associated with that account, like for e.g. linked to a set of OAuth credentials etc. But fundamentally there is only one account. If your user has registered once using a social account and then try to register again on your site, send them over to the social site which they used to register the first time and ask them to login there. Then log them into your site automatically. If the user has an account with your site and then tries to register again with a social account, tell them that you already have an account on the site and ask them to login. IMHO, keeping separate accounts and trying to merge them is a messy idea.
I would provide two sets of behavior, one when logged in and one when logged out.
When logged in, you provide the ability to link to new third-party accounts. For example, you sign up with email address and password, then log in, then you can link your Facebook account. To link your Facebook account you authorize with Facebook and then store the Facebook information in that user account record.
When logged out, you must log in with existing credentials. If, when logged out, you try to create an account with an existing email address, you either prevent the log in, saying "an account with that email address already exists", or you immediately challenge the user to log in to merge the account (in which case it works like the logged in case when linking an external account, only with the order of authentication operations reversed).
In case it's not clear from the above, I recommend having a single user account and a way to record linkages between that account and external accounts. You can do this in NoSQL buy just adding fields to the user document or you can do this relationally by having a table representing external accounts with a foreign key linking them to the user ID.
Beware not to use oAuth 2.0 !
The lead author himself resigned as it's not as safe as the 1.0 version.
You should prefer oAuth 1.0 or OpenID.
You can also have a look at Persona from Mozilla
I have a project where I am using Selenium to test the Facebook auth. I created a Facebook app, created a test user inside this app and created some tests using Facebook login. Until now, it was working. But during the last two weeks something changed in Facebook and my tests are failing. It is due to interface changes in permissions dialog (I am targeting the button by his id). The second problem is that I don't get the email address from Facebook test user but a proxy email which is longer than 75 characters (my db field length is hardcoded in framework I am using).
If I log in as a regular user, it is working correctly and I get this permission box:
But when I log in as the test user I created (via 'switch to' in app's developer roles), I get this box:
I tested it ~2 weeks ago and this was yet working. Today it is changed. So my questions:
How to get back the old permissions box for test users?
How can I get the real email address and not the proxy?
Thanks!
I experienced the same problem with the Auth Dialog. I tried it with some old and new apps with various settings including March/Apr. 2013 Breaking Changes enabled/disabled, but it didn't help.
However, I guess I can help you with the email problem. When you login as a test user and go to account settings page, you will see the test user's primary email addres. By default this should be a really long one like the image I attached.
Facebook Platform returns this primary email address. If you pass the Auth Dialog with your test user account and see the privacy setting page, you will find the default primary email address is shared with the app. You have to provide a new email address for the test user and set the new one as primary email address via account setting page.
Why is the Login Dialog different with a test user?
With your test user, you can see the future of login dialogs. In fact, this isn't "not working" but this is an update which was unveiled on December 2012. Let me quote:
Our Login dialogs have undergone a redesign to make it easier to
understand permissions that apps request. We've simplified
presentation and have also updated our language for greater clarity.
“Basic info” has been renamed to “public profile and friend list,” to
reflect what what is being shared. Apps accessing your public profile
get your name, profile picture, age range, gender, language, country
and other public information.
Source: Providing People Greater Clarity and Control, developers.facebook.com/blog
The reason why you don't meet this update with a regular user, is that Facebook doesn't use to update everyone at the same time. They partially launch updates depending on the country, the type of account or some other parameters I ignore.
Example of a partial update (unified_message FQL table) dedicated to developer accounts:
We are providing early access to this API for registered developer
accounts only until the new messaging system is broadly available. You
should use the message table for production applications at the
current time.
In our case, we now know that test users can access to the update, but it is also said:
We have already launched many of these improvements as part of our
iOS6 integration and are now rolling them out more broadly.
About proxy emails
In fact, proxy emails are a way for any users to keep their real email anonymous. You have to consider proxy emails.
When joining an app, the user can choose between a real email and a proxy email:
Other thing you need to expect are users who didn't validate their account when connecting to your app, a case which is possible as described here and here.
Then, why do test users give back a proxy email? Because test users (being bots and having fake emails) didn't validate their emails.
You see that in at least 3 cases (and finally, test users are a good example), you need to handle these proxy emails. They are incidentally or accidentally met by developers and they can't be neglected. For your case, you can still try to disallow tests users who have a proxy email from accessing your app. But you should accept them and shouldn't force them to share their original e-mail addresses. A better solution is that you validate the test users emails:
Connect to the test user account that gives a proxy email
Add an email address (password needed here),
Go to the email mailbox and click on the validation link,
Set the new email address as primary,
The test user should now give his original email and not a proxy anymore!
Currently on my website, users login with their login id and password, they are also required to enter their email when they register. Both login_id and email column on the users table have unique index. users table also stores other data associated with the user such as gender,last_name,first_name but these are optional (nullable) fields.
There are two changes I would like to make to the website.
The first one is, users can use their email (in addition to login_id) to login. For new users, when they register, they no longer need to provide a login_id because they will be using their email to login.
The second change is, they can login with facebook. For new users, if they login with facebook for the first time, their facebook uid will be obtained and stored in my database. This means I will have to add a facebook_uid column on the users table.
For existing users, when they login with facebook for the first time, I should first obtain their email address from their facebook profile and then check if there already exists a record using that email in the users table, if yes, their facebook uid will also be stored on the facebook_uid column on that record.
According to facebook, its platform supports two different OAuth 2.0 flows for user login: server-side flow and client-side flow. Which one or both is required for this use case?
Also, what problems can be anticipated when I implement the features like I describe above?
You could take either approach for this, it's entirely up to you. Both methods will give you the data you need, it's a question of how comfortable you are working on the back vs front end. You just need to ask for permission to access to the user's email address.
Problems that could happen: I'm not sure but there may be legal restrictions on storing the user's Facebook ID. Also, what if someone (not me, an evil person!) registers with my email address and you don't validate that they really have access to that address - then when I log in via Facebook, the app will assume we're the same person and the evil hacker now has access to my account. Unlikely scenario but could happen...