I'm a developer, and not in Sales.
I signed up for a free developer account, which has access to mock data:
Username: my.name#company.com
Email: my.name#company.com
I'll call this the "dev account"
Later I wanted to access to our company's actual customers, just to look around. Our admin gave me a different, regular login (she said it complained when she tried to use my existing email). That account is:
Username: othername#company.com
Email: my.name#company.com
I'll call this the "user account"
You'll notice the username is different, though the email comes to the same place.
I've been working with the dummy data that comes with the developer account. Now I'd like to access some of our real data via the REST API. It's not clear how I'd do that, and I don't want to blindly experiment and get into some type of weird state.
When I'm logged in as the "user account", and then access the developer website, it wants me to create another developer account. I'm not sure that's right. Also, the "Email" field would be the same as both my current "user account" and "developer account".
So how do I go from being a regular user to a developer against my company's actual data? Ideas I had:
Somehow link my existing "dev account" with my "user account" ? Not sure if I'd do this, or if it's something our admin would need to do?
Or maybe create a second developer account, having already been logged in as my "user account", and it will somehow magically associate them? It says "Select a unique username", but I already have 2 (old dev account, and new user account). I don't want to experiment and make things worse.
Some other way to do this?
Can I even create another developer account with the same email? Won't it complain?
I did do some google searches, but somehow I'm not hitting the right keywords. This seems like a basic thing that many folks would have to do at some point.
An aside: It's odd that it wants my zip code. Not sure if that's my home or work zip, and what if the office or my address changes? (actually likely) Most online services don't care about that...
You don't mention how you're accessing your data from the developer account, but somewhere you are authenticating (either via OAuth,or via a soap login call) simply change this to provide your user account credentials and you should be good to go.
You don't need to have a matching account on the developer website to make API calls, or link your developer & user accounts.
Related
While working with Google Action Console OAuth, it was rejected for the following reasons.
please, Help me.
Based on the line, "We couldn't find account creation/linking prompt", I'm guessing your OAuth page didn't have a "Create an account" link.
If you're telling them you want users to use your website to create accounts, users need to be made aware how to do that.
If you already have that, add "users can create an account on our OAuth page by clicking [Create an account]" (or however you say it) to your Testing Instructions and resubmit.
I wrote an app script which provides a web UI for data entry into a team calendar. I published it using G-Suite super admin account and added it as Trusted App under Security/API Permissions. "Trust domain owned apps" is checked under "Internal App Settings".
When a G-Suite user in our organization tries to access the app, he sees
"The developer of ShiftSchedulingApp, admin#_our_organization_.org, needs your permission to access your data on Google."
Those brave enough to click "Review Permissions" are taken to the next message:
"ShiftSchedulingApp wants to access your Google Account. See, edit, share, and permanently delete all the calendars you can access using Google Calendar"
Of course nobody wants to risk losing all the calendars on their Google Account and this is where it ends.
How do I get rid of this misleading message? It's not Google account, it's their organization account on G-Suite. It's not all their calendars, it's the shared team calendar only. It's adding data, not permanently deleting calendars. It's published by their administrator in their G-Suite, not an unknown 3rd party.
I spent days trying to make this message go away but no luck. App must be executed as an accessing user and not as publishing user because their user ID determines what shifts they can fill on a calendar.
I'd appreciate any hints pointing me the right direction.
I experimented with variations of the two-app approach as suggested.
The app which provides the UI needs to read the calendar to display available shifts - so I can't get away from the user authorization prompt.
Another variation I tried was having one app do everything and run as me, and another do nothing but return Session.getActiveUser(). I tried calling the 2nd one from the 1st one on the client side via XMLHttpRequest. It would be ideal for my needs - but I hit CORS error as apps URL is script.google.com but it actually gets redirected to script.googleusercontent.com. There doesn't seem to be a way to set CORS in Google App Script.
Although I was not able to find a way to avoid prompting users for authorization when executing the app as accessing user, it turns out my reasons for doing that were based on a false premise.
I chose to publish app as accessing user because I thought that's the only way to get accessing user Id - which is true for non-G Suite accounts.
However, when app is published by a G Suite account, the app can get accessing user ids within the same G Suite domain even when it's set to execute as publishing user.
Thanks Niek and TheMaster for your help!
If you just need user ID, why do you ask for all those permissions?
Possible Solutions:
2 web-apps- One running as you and another as user accessing (with only profile) permission. The second one will be the actual web interface and POST necessary information to the first one with privileges. OR
Implement your own web-app Google-sign in1
Use the least permissive2 scope3
I have a "Sign in with Google+" button on my page. When people click on it, I want the only thing they authorize to be "View your email address."
I don't want "Know who you are on Google" or "View basic information about your account." I only want their email address.
I'm playing on the OAuth 2.0 Playground (https://developers.google.com/oauthplayground/) and see this:
Scope: email
Requests:
Know who you are on Google
View your email address
Scope: https://www.googleapis.com/auth/userinfo.email (and this one is deprecated)
Requests:
Know who you are on Google
View your email address
Indeed, I've noticed that too. And I found an explanation from February 2013 here:
This is an intentional change to more precisely communicate to users the set of permissions that is being granted. Through knowledge of the user's email address it is possible, via indirect means, to locate the user's profile address. In the interest of more accurate disclosure, thus, we are prompting users to approve such disclosure.
Not exactly what you want, but combining profile and email will at least give one a less scary description for the first:
This app would like to:
View basic information about your account
View your email address
...with the help for the first saying:
More info
View your name, public profile URL, and photo
View your gender
View your country, language, and timezone
To me, this feels better than the vague This app is requesting permission to associate you with your public Google profile which one gets as the More Info for Know who you are on Google+, when not explicitly using scope profile, or when using scope openid.
As an aside: LinkedIn's OAuth 2 also always needs a user to grant access to Your Profile Overview, even if an application only needs some unique identifier. Other than with Google's explanation in Owen's answer, I assume LinkedIn really wants developers to use their network features.
One of our customers uses IBM's Security Access Manager (ISAM) for Enterprise Single Sign-On (ESSO), which uses a piece of software on the client called AccessAgent. From what I understand it's basically a glorified password manager.
This customer uses the software to autofill the username/password prompts on our web site so that they can log in; however, the software also tries to do this on the "Reset Password" page which comes up in the event that the software has a different password stored than what the user actually has. When users hit the reset page, AccessAgent automatically redirects them to the home page for some reason.
The first thing I tried was renaming the field from "username" to something non-semantic in hopes of throwing the software off. This worked for a few months but it has apparently 'learned' again that "hey, people put their e-mail address in here, I'll try to log them in!".
Past efforts to train individual users to turn off the software have not worked, and we continue to get a lot of "your password reset page doesn't work" tech support requests.
My question is this: Does anyone have any experience with this software, and is there a way to disable it for my password reset page? Either via HTTP header or tag or something?
I am brand new to Visual Studio 2012 and MVC 4, and I've been working with the SimpleMembershipProvider via the WebMatrix.WebData library.
I'd like to integrate Facebook as an external login source down the road, but it's not a requirement as of right now. However, to get a decent feel for what it would take, I've been following the tutorial and guide found here - http://www.asp.net/mvc/tutorials/mvc-4/using-oauth-providers-with-mvc.
My question :
If a user has already been created using :
WebSecurity.CreateUserAndAccount(model.Email, model.Password);
WebSecurity.Login(model.Email, model.Password);
Can they be "upgraded" to an oAuthMemebership account in the future, if they choose to use their Facebook credentials instead of the email and password they created when first signing up?
I couldn't find a clear answer to this question in the guide, or elsewhere, so I'm hoping someone can clarify how that process may work.
The SimpleMembership setup allows for a local and multiple OAuth logins all sharing the same UserProfile - so a single user can login with either a local password, or FacebOogLiveWitter.
(I should state, that I'm assuming in this answer that the OAuth provider does not send back a matching piece of information for a local account. If they do then the principles of actually performing the merge are the same, but the complexity and steps are vastly reduced.)
The OAuth registration process will refuse the user if they use an existing user name, rather than try and merge two accounts. Therefore this isn't simple, you'll have to build the functionality yourself. The process is complex as there are many directions the user can approach this from (so you could simplify by only supporting one or two), and you need to enforce security as well in case someone tries to merge into an account they don't own.
I will assume you are comfortable with the link you've posted, and you've followed the Facebook help at (for example) Facebook Login and The Login Flow for Web (without JavaScript SDK) so you have a working test application.
Your general process has to have multiple user journey approaches to make sense to a user:
for a logged in user (with a local account)
let them login to facebook and associate the accounts
let them merge an existing account on your site which uses a facebook login
for a logged-in user (with a facebook account)
let them create a local account
let them merge an existing local account on your site
for a non logged in user who tries to register a local account
let them merge this new account with a facebook login that is already registered, and do that as part of the registration process
for a non logged in user who tries to register (or log in for the first time with) a facebook account
let them link this with an existing local account as part of the registration process
etc.
ASK PERMISSION
(You can skip this if the OAuth provider has sent back a matching identifying piece of information, such as an email address).
You should enforce confirmation security, usually through email confirmation sent to the target account of the merge. Otherwise:
someone can login to your site with facebook for the first time
during that process say they "own" the email address or username of a local account (remember, facebook won't necessarily confirm what their email is for you)
and therefore gain access to the existing local account
So, once the merge "request" is made, you need to ask for permission to proceed from the target account of the merge.
The MVC 4 AccountController
I will use Facebook as our OAuth example. To compare what happens when you register a user on your local authentication framework vs. OAuth:
Local: creates an entry in webpages_Membership and an entry with the same UserId in UserProfile (assuming you are using the default tables for the MVC 4 application template)
OAuth: creates an entry in webpages_OAuthMembership and an entry with the same UserId in UserProfile
Now let's look at what happens when a user signs in using Facebook for the first time:
They click on Login using Facebook (or whatever your button says)
they get taken to facebook to login
they succeed (let's assume that, and ignore the failure case)
they then get sent, invisibly to them, to /Account/ExternalLoginCallback
OAuthWebSecurity.SerializeProviderUserId is called, passing the OAuth details to that Action
They get redirected to /Account/ExternalLoginConfirmation and asked to provide a username for their new presence on your site
If that user name is available then UserProfile and webpages_OAuthMembership entries are created
This process is your chance to "join" the accounts by matching some unique piece of information. As long as you end up with the same UserId in UserProfile, webpages_Membership and webpages_OAuthMembership you should be ok. So we have to intercept the process at the point of /Account/ExternalLoginConfirmation.
If the OAuth provider has sent back a matching identifying piece of information, such as an email address, this becomes simple, test for this in the ExternalLoginConfirmation action, and auto-merge using a similar process to the one outlined below.
However, I think you can't/shouldn't assume that the user uses the same email address for your site and OAuth, (nor should you for many reasons). Also, probably in the T&Cs for something like FacebOogLiveWitter it stops you asking for the email of their account anyway, and if they don't currently they might in future.
So instead, you could link the accounts based on alternatives, like username or email address, or phone number. Either way you are going to need them to input some identifying piece of information that is unique against an account, and will pull back the target account.
Wrapping up
So to put this all together: In the first part of this answer I outlined how you will need to consider multiple user journeys to merge accounts. I will use the example 4.1.
Your process will need to:
(Assumption - when a user first registers with a local account, you ask them for an email address and validate it or assume it is valid)
Let the user login with facebook for the first time
at Account/ExternalLoginConfirmation ask them if they want to
Create a new account with you
Use their facebook login to access an existing account
Assuming the latter, then you log a request in a new table (maybe "MergeAccountRequests") with:
The facebook account UserId
The target merge local account UserId
An authorisation code to use in the email you need to send
(From this point on, if they login without confirming that merge, they will have to get sent to a page to ask them to confirm, rather than create objects in other db tables which you have to worry about later)
You then send an email to the address of the target merge (local) account asking for permission to complete the merge (a standard confirmation email, with a link)
When they click on that link, or enter the code you sent them (you could use SMS as well as email) then you need to merge the two accounts
Choose the "new" and "target accounts (in this case "new" is the facebook account as you don't have data associated with it yet)
Delete the UserProfile of the "new" account
Change the UserId of the "new" account webpages_OAuthMembership table to the same as the "target" account
Log the user out (so there are no complications depending on which account they are currently logged in with)
Display a message to the user telling them the merge is almost complete and that they can now log in with either account to confirm and complete the merge
Rather than send them to a login page, i would give them the login options alongside the confirmation message.