SMTP.Send with Outlook REST V2.0 API works fine.
Same client using Graph V1.0, the only change being the ‘scopes’ URIs, gives a ‘535 5.7.3 Authentication unsuccessful’.
However, AAD’s Sign-in logs (‘User sign-ins - non-interactive’) for the app show ‘Success’.
Unless Graph SMTP.Send uses a different server URI than the published https://smtp.office365.com, this should be impossible.
The problem is pressing because the Outlook REST V2.0 API will be decommissioned in November '22.
Background detail
Uses V2 Authorization and Token endpoints, and scopes URIs of https://outlook.office.com and (the default) https://graph.microsoft.com respectively. Detail of the event in the AAD Sign-in log tally exactly with the (jwt decoded) content of the Access token. ‘User-sign-ins (interactive)’ show nothing of relevance. Client’s HTTP is via Guzzle.
Related
EDIT: In case it helps others who find this, the fact that Gaia clears cookies after Chrome restart is known behavior. They recommend the use of Chrome login. See more here.
The core question: how do I fetch Google OAuth access tokens in the background from a Chrome extension without using the getAuthToken method in the chrome.identity API? This method forces users to login to Chrome, which isn't ideal for our app. There's also no way I can find to retrieve OpenID Connect ID tokens using the native methods exposed in the identity API.
Currently, I'm fetching tokens using the launchWebAuthFlow method from the chrome.identity API. This method launches an "Identity API Scope Approval UI" window in which the user makes the initial OAuth grant. This window (referred to as "gaia") has its own session / cookie data, separate from a browser session.
After the initial OAuth grant, the extension periodically retrieves access tokens in the background, and subsequently fetches data from Google APIs (e.g. Drive). This works well. When a user quits and re-opens Chrome, however, fetching access tokens fails - gaia loses its session cookies when Chrome restarts, so running the launchWebFlowAuth method doesn't complete because Google can't authenticate the user (unless we prompt the user to login in the Identity API Scope Approval UI again). Others seem to have had the same issue.
Google Sign-In would be ideal, but it doesn't work in Chrome extensions (I'm getting the same "Invalid cookiePolicy" error as the author of that issue).
Any advice on how to best handle this use case would be very much appreciated!
My iOS application uses Mailcore to access a user's email account. Sending and receiving is done via SMTP and IMAP, and both processes work as expected for Gmail and Outlook (which both use OAuth for login).
I just added Yahoo (as well as some other providers to the app who do not use OAuth) and for all of these providers I am having an issue specifically with sending messages.
The issue is that although messages DO get sent successfully from my application, they do not appear in the sent folder on the web for the provider.
For example, if I log into my Yahoo account in my application, and send a message to my Gmail account, the message appears in my Gmail inbox on the web, but not in my Yahoo sent box on the web.
I tried adding Yahoo to the regular mail app on iPhone and sending a message from this account - this worked fine - the message shows up Yahoo sent box on the web. So, I then compared the headers of the two messages (the one sent from mail app and the one sent from my app) and the only obvious difference I see is in the line 'X-Rocket-Received':
Mail App:
X-Rocket-Received: from [11.180.250.219] (userName#71.208.72.234 with xymcookie [216.39.61.254])
by smtp203.mail.ne1.yahoo.com with SMTP; 23 May 2014 08:19:54 -0700 PDT
My App:
X-Rocket-Received: from (userName#118.41.27.139 with plain [98.138.105.21])
by smtp214.mail.ne1.yahoo.com with SMTP; 23 May 2014 08:58:29 -0700 PDT
Can anyone answer any of the following questions for me:
1) What does X-Rocket-Received mean?
2) What is the significance of "with xymcookie" versus "with plain"?
3) Is my issue likely to do with my not having an xymcookie?
4) Where might I begin to solve this issue?
Many thanks.
Additional information:
It was placed there by some server along the way. It is a non-standard header. It appears similar to a standard SMTP Received header though.
'xymcookie' is a non-standard authentication method used by Yahoo. It is not, as far as I can tell, publicly documented.
No.
See Remy's answer. Use IMAP Append for most servers. Gmail does not require it, but that is non-standard.
Sending an email with SMTP directly does not put the email in the provider's Sent folder. You have to log into the provider with IMAP and put a copy of the email into the Sent folder as a separate operation. Higher level apps, like iPhone's mail app, handle these details internally.
Is it possible get notification on application level on client side in iOS(and Android) whenever some changes happens like new file/folder added or removed on Box.net? Please confirm if SDK supports this behaviour, if not then is there any way to implement this behaviour on client side.
Thanks.
You should be able to get notifications about events happening in a user's account by using the /events endpoint:
http://developers.box.com/docs/#events
Essentially, you'll need to authenticate as the user via OAuth2 and issue an OPTIONS request to the /events endpoint to get a realtime server URL. You should set up a long poller to poll that realtime server, and when it issues a response that notifications are available, issue an authenticated GET request to /events?stream_type=....
Both the iOS SDK and the Java/Android SDKs should support this.
https://github.com/box/
I have this app that uses EWS to access mail, using the standard /EWS/Exchange.asmx SOAP endpoint.
One my user's mail servers is protected by Microsoft Forefront, and the initial HTTP request to
https://server_name/EWS/Exchange.asmx
is redirected (HTTP 302) to:
https://server_name/
CookieAuth.dll?GetLogon?curl=Z2FEWSZ2FExchange.asmx&reason=0&formdir=3
which is an regular HTML page, the point of which, I guess, is to make the user authenticate "manually".
I've not heard about Forefront until today, not sure how to handle it.
Is this normal behavior for Forefront (i.e. it always redirects the initial HTTP request), or is it triggered by something in my app? For example, user-agent?
If it's normal, how am I supposed to get past this page and access /EWS/Exchange.asmx?
If it's triggered by something my app is doing, how can I find out what it is?
My code runs on Android and forms its own XML requests without using any SOAP library. At the transport level, I use Apache HTTP client components. The code works fine with Office 365/Exchange Online, and, according to user reports, "self-hosted" corporate Exchange servers with NTLM.
However, in this case, I'm not even getting an HTTP 401: the HTTP 302 is returned by the very first HTTP roundtrip.
Trying to preemptively authenticate the initial request using Basic authentication didn't make any difference.
The user who reported this issue also mentioned that another EWS based app works, so there must be a solution to it.
Either I'm dense, or the docs assume I already know what they're telling me, but I need some clarification on doing authentication for a box.com app. I really don't understand whate's going on. As I read it:
the app running on the user's machine sends a request to Box, including all the little secrets (Which aren't all that secret any more if the user knows how to read the code).
The user is directed to the Box login page, which then sends the user to my server (with no page specified) attaching an authentication code.
The app somehow magically gets that code back from my server and sends a request to Box for the access token.
Box sends the access token to my server?
The app again magically gets the access token from my server and sends its APT requests.
Obviously I got lost somewhere.
And, why do I have to have a server involved in the process? The article on making a JavaScript app refers to a direct request for a token. Is there documentation on that somewhere?
You register your application on Box
After registration you receive clientId and clientSecret once on Box website
You hardcode your credentials somewhere in your application
First time your application needs to access Box API it should redirect user to https://www.box.com/api/oauth2/authorize, specifying your clientId, clientSecret and redirectURI as parameters. About redirectURI see below.
The box.com website opens. User enters his own credentials in the web form on box.com
User allows your application to access his files via API on the box.com website
Box redirects user back to you application using redirectURI specified before. One of the parameters to this request is "code". This is a very short-lived (30 seconds) access code that is only aligable for obtaining real access token.
During next 30 seconds your application should make another call to Box API to next URL: https://www.box.com/api/oauth2/token, specifying the previously obtained code. If everything was correct, your application receives an access_token, a refresh_token and "expires" values.
Now your application can make requests to Box API, specifying access_token every time
access_token expires in number of seconds, specified in "expires" field. It should be about 3600 seconds or 1 hour. Each time your application sees that access_token has expired, it should make another request to Box with the refresh_token and obtain a fresh access_token for another 1 hour.
refresh_token itself expires in 14 days
Note: if you develop a desktop application, then you should open browser for user on the step 4, redirectURI should be something like http://127.0.0.1:8080/Callback and you should run a small webserver just to catch the redirect with the code as in step 7.
Box requires that you specify a redirect_uri in your application's profile, and it must be an HTTPS URL.
As a result, it is not possible to use box with what google's oauth2 documentation calls "Client Side" or "Installed" applications, only "Web Server Applications" are allowed. Web Server applications do not have the secret leaking problem, because only the server knows the secret. You can pass the access token from your server to javascript on the client after
the oauth transaction is complete, if you want the client to make api requests directly.
In your question you are not totally clear in what you are actually trying to produce.
I however suspect that you are trying to write a client application what needs to authenticate to box using the OAUTH2 solution they have delivered in API V2.
If this is for an IPhone for example BOX has a great example of how to handle it.
In a WinForm application you would need to capture the resulting code sent back by box in the browser1.isnavigating event.
Windows console application you register a custom URI registration to collect the code.
Neither of these need to be registered in the API developers Application on box as you would pass the redirect required in the request to box.
If this does not point you in the right direction and your writing a .NET app then post again and I will try to clarify a little more.
Box requires some form user interaction which is short sighted in my opinion but try a web service that simulates a user interaction which then you can save/pass the token to your application to sync up with the Box "Cloud".