I am using htmlunit to automate logging on to a server with google (the red "Sign in with Google button"). This redirects https://accounts.google.com/ServiceLogin, where I must write the email and password attributes every time. Compared to if I go to that url in my browser, I can choose which account I want to use, I don't have to type in my password.
Where is that data stored, and how can I emulate it in htmlunit?
Related
Is there a way to automatically authenticate the google javascript api client, without user interaction?
Something like this:
User loads webpage -> webpage automatically signs in into a predefined user account -> api calls get executed
Basically i want to prevent the popup where you have to select an account and sign in to it. As the account which will be signed in is always the same.
EDIT:
pinoyyid answer looks promising and is what im looking for. But this only works if the user has signed in with an account at least once, if im not mistaken.
Now i dont want to use an account supplied by the user, but a predefined account which i am the owner of and sign this account in.
Im not entirely sure if this is even possible, as i have to provide the password/some authentication code to google and somehow do this in a secure way.
Use Case: The website will create a Youtube Broadcast via the Youtube Data/Livestream API for the specified account.
Yes you can do that. Referring to https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow
there are three pieces of information that will get you where you want to be:-
The OAuth URL can include a login_hint which is the email of your intended user
The OAuth URL can also include prompt=none which will do its work silently
This all needs to run in an iframe because this is based on origins and redirects.
==EDIT==
If the requirement is for a browser client to connect to a Google Account other than that of the browser user, then this is not possible. It's kinda obvious really that to do so would require a credential in the browser which by definition is not a secure environment.
The approach I would take would be to use a service such as Lambda or Google Cloud Functions (or whatever marketing name they have this week) to create a proxy for the corresponding Google API using a credential stored server-side.
I am trying to make the Pre-launch report work well to cover more screens (beyond the signin screen) by providing Sign-in credentials, however after providing the testing account the crawl still cannot beyond the Sign-in screen. This is my configuration:
I can confirm the username/password resource name are correct, but in my app, they are in two separated screens.
I.e.: Input username (actually it requires a phone number) first then tap on Next button in this screen to see the screen for typing password (actually it is the 2fc via SMS),
and after typing in 2fc, the app logs the user in automatically, so there is no Sign-in button.
My question is does Google supports my use case stated as above? I.e.: if username and password are not in the same screen, is Google still able to crawl beyond the sign-in screen?
The crawler will use the provided sign-in credentials when it matches the corresponding resource id on a given screen. So, having username and password on two different screens is not a problem. The tricky part is getting from one screen to another (in your case, it is clicking the Next button) such that the crawler has an opportunity to type in the password. If the crawler does not perform this step on its own, you can guide it with a Roboscript - that is, instead of using sing-in credentials, record a Roboscript in which you type in the username, click Next, type in the password (basically, the steps you mentioned above), and then upload this Roboscript for your pre-launch report.
I have gone through the Instagram Authentication documentation and I could see that there is no direct way to authenticate other than taking the user to a URL specified by the Instagram.
This is what Instagram documentation says.
In order to receive an access_token, you must do the following:
Direct the user to our authorization url. If the user is not logged
in, they will be asked to log in.
The user will be asked if they would like to grant your application access to her Instagram data.
The server will redirect the user in one of two ways that you choose:
Server-side flow (recommended): Redirect the user to a URI of your
choice. Take the provided code parameter and exchange it for an
access_token by POSTing the code to our access_token url.
Implicit flow: Instead of handling a code, we include the
access_token as a fragment (#) in the URL. This method is less
secure, but allows applications without any server component to
receive an access_token.
See we should take user to a particular URL. Instagram uses OAuth 2.0.
But the thing is that there is a Mac App named Flume, which does not take user to a URL. It simple lets the user enter their username and password, and Flume connects to Instagram API,and the user successfully gets logged in and able to see his media content.
I wonder how Flume doing this? Am I understanding the documentation incorrectly?
Please help. Thanks in advance.
You're reading the documentation correctly.
Flume doesn't use the Instagram API, so it is not affected by its limitations. Instead, it will likely use web scraping by opening the Instagram website in an invisible browser instance, there entering the user data and commands on the behalf of the user, then scraping the results from the next invisible browser page etc.
There are different approaches on how to achieve this in OS X, a starting point could be Web scraping in Objective C. For a conceptual overview, you could have a look at RoboBrowser, which is a Python library but gives you an idea of how this works.
Instead, it will likely use web scraping by opening the Instagram website in an invisible browser instance, there entering the user data and commands on the behalf of the user, then scraping the results from the next invisible browser page etc.
This is actually false. Flume has found a way to use Instagram's internal API to display content. Using a man-in-the middle proxy client such as Charles will show that the network requests that the Flume app makes are very similar to the network requests made by Instagram's different native Apps. Flume mimics Instagram's network requests in order to set HTTP headers/cookies/auth data to retrieve/post information.
I'm happy to post pictures/files to verify this for anyone that may wish for further proof of this.
Is it possible for me to create an application that can send our requests to access to users' Google Calendar so that I can see the events in there and be able to add, edit, and delete events?
I do not want the users to log into my website to enable this access. Rather, I want to be able to send this request, perhaps via email.
Alternatively, perhaps they could log in the web app and authorize access themselves somehow.
One option would be to e-mail the user a link to the OAuth 2.0 consent screen. The users would still need to open the link in a browser, sign in to their Google account (if not already signed in), and click the "Authorize" button to grant your application access to their Google calendar events.
First, you will need to register your application as a Web App in Google's Developer Console (just like for any other application) and obtain a client_id. Be sure to fill in the name of your application and a link to your website in the "OAuth consent screen" section, because these values will be shown to your users when they click the authorization link.
Then, follow these steps:
Send the user an authorization link in an HTML e-mail message. The link should be constructed according to the guidelines in "Redirecting to Google's OAuth 2.0 server", and pay attention to the following aspects:
Ensure that the redirect_uri parameter in the authorization link points to your application.
Since you already know the e-mail address of the user, consider including the login_hint=<email address> parameter to bypass the account selection screen.
Important: provide a value in the state parameter so that you can link this authorization request with the user.
The link should be placed in an <a> tag somewhere in the body of the e-mail: Allow access to my Google calendar
When the user clicks on this link, their browser will open and show the standard Google consent screen:
Once the user has made a choice, their browser will be redirected to the redirect_uri which you have provided.
Make sure that the redirect_uri will work even if the user isn't signed in to your application. Capture the state and authorization_code values which Google appends to the redirect_uri, and then return a confirmation page (e.g. "Thank you for giving us access to your Google calendar" would be a good idea).
Using the state and authorization_code values, follow the rest of the standard OAuth 2.0 flow and retrieve a refresh_token which will allow you to access the user's Google calendar from your application.
Keep in mind that the calendar owner (the user who is clicking the link in the e-mail and granting your application consent to access the calendar) may not even be a user of your application. This is why it is important to provide as much information as possible on the consent screen and in the confirmation page.
Since your confirmation page will be loaded even if the user does not grant your application consent, you could take the opportunity to give the user a full description of why you are asking for access to their calendar and provide a link that will take them back to the consent screen. This should increase your success rate.
Every request your application sends to the Google Calendar API must
include an authorization token. The token also identifies your
application to Google.
Your application must use OAuth 2.0 to authorize requests. No other
authorization protocols are supported. If your application uses
Google+ Sign-In, some aspects of authorization are handled for you.
The details of the authorization process, or "flow," for OAuth 2.0
vary somewhat depending on what kind of application you're writing.
For more details on the workflow to gain access click here. Once your app has access, it will be able to view and edit a user's calendar events, depending on the approved permissions.
I'm working on a site that requires the user have a unique username to use all services on the site. They cannot self-change this username for community fairness.
We would like to allow users the simplicity of registering/logging in using their facebook accounts, but this username requirement is obviously a hurdle.
The only idea I have come up with is after the connect process, send the user to a final step page where they enter a username. The only downside to this is that the user has the ability to navigate away before entering a username, meaning we need to add further layers of checks to several site functions to ensure a user has a username, and prompt for one if not.
Any ideas on how to streamline this during the connect process? Any site examples of similar implementations where auxillary info is required to use some or all site features?
Have you looked at Facebook's registration plugin?
The Registration plugin allows users to easily sign up for your
website with their Facebook account. The plugin is a simple iframe
that you can drop into your page. When logged into Facebook, users see
a form that is pre-filled with their Facebook information where
appropriate.
https://developers.facebook.com/docs/plugins/registration/
The plugin also allows you to add custom fields so you could simply add your username field.
There are a load of advanced features including validation, here's an example in the Facebook documentation that includes the username field and checks to see if it's available
https://developers.facebook.com/docs/plugins/registration/advanced/#async