I'm working on an iOS application and what I'd like to do is have the app ping one universal Gmail account to check for the most recent email.
I went through the guide from Google at https://developers.google.com/gmail/api/quickstart/ios?ver=swift, but the result did not work. After some googling, it appears that some functionality may have been changed, but they haven't updated their documentation yet.
Is there a way to send credentials via https to Gmail and get email messages back? I have an OAuth key via the Gmail API manager, but when I pass it as "access_token", the response says "Login Required".
AFAIK, an error response "Login Required" can be encountered if you try to list the buckets for a project that do not provide an authorization header.
If we check Users.messages: get, it's noted that it requires authorization.
For this, you may want to check Authorizing Your App with Gmail wherein you will find these basic authorization pattern:
During development, register the application in the Google API Console.
When the app launches, request that the user grant access to data in their Google account.
If the user consents, your application requests and receives credentials to access the Gmail API.
Refresh the credentials (if necessary).
Furthermore, if your application needs to access Google APIs on behalf of the user, you should use server-side flow. Please see Implementing Server-Side Authorization for more information.
Sometime back I was involved in writing a sample application to access email from gmail but using C++ on windows. The code is at https://github.com/Panchatcharam/simple_gmail_api. I was able to successfully get emails.
Related
I'm supporting an installed application, a standalone desktop application. I would like to enable people whos use this application to send out emails using their Yahoo email account.
I know that I will need to create an application in Yahoo Developer Network, then generate a URL to request a Yahoo OAuth2 token first and then use this token, I can use SMTP or OpenID API to send out emails.
I've encountered a lot of problems while creating my application in Yahoo Developer Network, and requesting the token. I've compiled them and I'm listing them below:
Confidential client or public client:
Yahoo explains that one should choose confidential client for traditional web application and choose public client for mobile apps, native apps, or single-page apps.
If confidential client is selected, there will be client secret generated; and if public client is selected, there will be no client secret generated. Plus, if I choose public client, which I did for my application, when I request OAuth2 token, I can choose to not include client secret as one of the parameters and it looks like that that is not causing any problem.
API Permission:
I took it as scope. But the strange thing is that it does not include anything like Google. Google states "Send email on behalf of customer", but similar choice in Yahoo is like OpenID Connect Permissions-Email, which has a brief introduction as "Access to email address and verified status".
There is another possible choice for OpenID Connect Permissions, as well. It's called Profile, having a brief introduction as "Access to common profile information (eg. first/last name, gender, etc.)".
Another strange thing about permission is that when I started to request OAuth2 token by opening a generated request url, after logging into my yahoo account, the page stated the permission as "Read Profile", which does not meet our expectation, as I took it. Plus, it does not have anything like sending email on behalf of customer.
Redirect URI:
In Yahoo developer center, for the application I created, I set it to localhost, port 55555, the same as I set for Google OAuth2.
I have reviewed some code examples, the code uses the secret, the stuff that only exists for confidential clients, or traditional web application, and stated that I need to develop a redirect web page in our website, which redirects to localhost, port 55555.
Redirect URI is also a required parameter when generating the OAuth2 token request url. If I state localhost as the redirect uri inside the requesting url, Yahoo page says "Oh, no. There had been some problems, please try again. Developer: Please send a valid request."
If I set the redirect uri to "oob", which means "out of boundary", as stated in Yahoo OAuth2 Guide, the generated url will succeed, but the same page shows up again after I login to my Yahoo account and grand the permission requested. Well the permission is also wired. It's "Read Profile", nothing about email sending.
I have searched Internet to find out what exactly those settings should be set for my scenario and read thoroughly through Yahoo OAuth2.0 Guide. But nothing is clear enough for me to do my coding job. Could anyone shield some light for me? Thanks in advance.
Plus, I'm thinking of getting help from Yahoo regarding this task, but it seems that they do not have any communication channels for developers like me. Anyone knows more about that and would like to share with me? Thanks, again.
I'm done setting up the server by following steps given here.
OAuth does work with google but only for web-client
On iOS client, I've followed steps to integrate google sign-in by following steps given here
Let's say there is a get route localhost:8080/api/v1/movies should be accessed by users who are logged in, how do I achieve that?
User has already logged in, on iOS client.
How do I pass iOS client's google authorisation information to server?
I believe that once your client has completed sign-in, you will have a GIDGoogleUser that provides access to an ID token (JWT) that you can supply to your server. Your server can then validate the token (that it was issued by Google) and extract the user's identity.
See: https://developers.google.com/identity/sign-in/ios/backend-auth
You may be able to use the Kitura-CredentialsJWT middleware to decode the token. Note that as of writing, the plugin only supports Codable routes, but there is an open pull request that adds support for 'raw' routing (using the Kitura-Credentials plugin mechanism).
Update: Kitura-CredentialsJWT support has now been released in tag 1.0.0.
I'm working on creating a REST API and one feature is to allow users to register. The general flow is the following:
The user specifies his email and password using the client application (SPA application) and presses the submit button.
A request to the API is made. The API adds the user to the database, generates a verification token and sends an email to the user.
The user verifies his email and clicks a confirmation link.
The API marks the user account as verified.
My question is regarding the confirmation link.
Should the link point to the client SPA application? In this case, the client application will make a POST request to the API with the verification token and the user email.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Another approach would be for the link to go to an endpoint defined by the API. In this case a GET request will be made with the user email and verification token and the API will set the account as verified and inform the user that his account is now active.
I have read that this approach doesn't conform to the REST principles because a GET request should never change the state of a resource. In this case, the user resource will be modified.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Thanks!
Should the link point to the client SPA application?
If your 'Client SPA application' is the sole frontend for end-users, then yes: it should point there. Some people deploy a separate oauth2 / authentication server but that doesn't sound like it's the case here.
The client application will make a POST request to the API with the verification token and the user email.
The token should be enough. I'd avoid sending email addresses through urls.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Both seem like really valid designs. If you want the API to be completely unaware of the front-end and support a multitude of frontends, it would make sense to me that the client sends their own endpoints. There is a security concern though, you don't want arbitrary clients to register arbitrary urls.
If you're just building a single frontend, I don't see a problem with the API knowing the activation url. It also sounds like it would be easy to change if your requirements change later.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Ultimately it doesn't really matter that much. Neither approach sounds like you're really painting yourself into a corner. Either you have a standard endpoint that uses a javascript HTTP request to activate a user, or you have a separate endpoint that redirects a user after activation. Both will work.
Use-case: Emails to be sent from a web-application upon an event, as someuser#somedomain.com via MS Exchange or Outlook.com, using the RESTful APIs exposed by Outlook.com. Only HTTP access allowed (=> no SMTP/IMAP).
All documentation seems to mention that the app has to forward users to MSOnline, sign-in and then use the authorization code sent back by MS online.
But, this won't work for a background task (=> no sign-in possible!) where a pre-built token(with some predefined scope) is necessary so that Outlook.com can be accessed via APIs to send mail as someuser#somedomain.com.
Any hints/pointers to how it could be done? Basically, automated authentication without explicitly signing in as 'someuser#somedomain.com' on the MS Online login page.
I did not find M$ documentation regarding Outlook REST APIs to be of any great help and found it to be pretty difficult to navigate/understand. :(
Thanks!
At some point you will have to have the user sign in to grant access to your app. So you would need to have some sort of user-facing web front end where they can do this. Once they have signed in and you've obtained an access token/refresh token, your background app should be able to use those tokens silently, without user interaction, at least until the user either revokes access or the refresh token expires.
Currently Azure (which provides the login/token functionality) does expire the refresh tokens after some time (90 days), at which point the user must sign in again to grant your app continued access.
We have a multi-tenanted/multi-domain app and we're looking at publishing on IPP. Because of the multi-domain nature our configured endpoints in the App setup are generic and users are then redirected to their specific account once their identity is established.
The issue is with C2QB WF3.0.
The test steps are:
go here: https://appcenter.intuit.com/Home/MyApps/
on the "Launch My Apps" tab, click the app
Expected Result:
the Sign In screen for the app is displayed
The requirement is:
if not still signed into the app, sign in screen is displayed
if still signed into the app, take user into the app
The issue is that the even if the user is currently logged into our application, it still requests authorization as per this message:
"domain" is requesting some information from your Intuit account
By approving this request "domain" will be able to access your:
Name
Email Address
The workflow that it is actually following is to perform a callback to our connect url. The normal way to determine which account the callback is coming from is via the realmId, but this is not received from Intuit and therefore it needs to be requested. Once a user has completed this authorization, it will not ask again. It should be noted that we're not actually requesting a name or an email address as the screen suggests.
We've been informed by Intuit that it should not request authorization and it is not part of the workflow.
We're wondering if anyone else has encountered this problem and if there is a workaround for it.
We discussed with the Engineering teams and they confirmed what Pete has mentioned above. This is not a bug and please follow the steps as Pete has mentioned.
If you want to replicate the 'access your app with appcenter flow', you have be either logged in QBO online company file in same browser session or navigate to the app via blue dot menu from your application or run your application from localhost(.net) and then go to Appcenter and login there on same tab and then click on your app.
Since your desktop application is running, your code will be hit.
You will then get the second Auth screen only for authorizing your company file. After authorization your realm will be set in a cookie and in the code you can see its value. You can replicate this behavior via firebug and see the qbn.parentid cookie value has the realm after authorization is done.