I want to read calendar events in my app from on-premise Exchange server. For exchange online, Office 365, I could use Microsoft's SDK for iOS. I want to know
Is there any SDK from Microsoft to support on-prem exchange server in iOS app
Is there any extension/plug in that enables my app to read calendar events from exchange server
Is there framework/service offered by Apple that can be used in custom apps to read calendar events?
Any link/info would be greatly appreciated.
As written in the comment. I personally would never ever enter my Exchange password in a strange app, which then access my Exchange mailbox (which also would explain the downvote). The app would then be able to write emails, read all emails ... means access everything in my mailbox.
So I think the best way to access the calendar in your app would be that your app access the user’s Calendar database using the EKEventStore class. However this has some limitations so normally not the whole calendar is visible here and most users sync only a subset. But for most apps this might be enough.
Via this approach your app also becomes more "universal" and can also work with WebDAV/CalDav calendars (e.g. Shared Calendars like google calendar).
Additional via that way you do not need to deal with:
bad network connections
Different authentication methods (e.g. two factor authentication)
SSL encryption (cipher vs. protocols vs. ...)
Related
I am integrating Onenote with my application. I am using MS Graph API's for getting data from Onenote. To consume the api's I am generating the token as mentioned at link get auth tokens.
I am registering my application at MS application registration portal. Do we need to purchase any kind of paid license to use services provided by MS graph API's.
The app registration process seems simple and doesn't differentiate between applications that can be used in production/test environment.
The app registration process seems simple and doesn't differentiate
between applications that can be used in production/test environment.
Apps registered in the app registration portal can be used for production or test environments. There isn't any switch that needs to be set when you're ready to ship. Congrats on shipping your app to production!
Do we need to purchase any kind of paid license to use services
provided by MS graph API's.
We don't charge for access to the API. Some of the services exposed in Graph via APIs require licenses like Intune. It sounds like you're using OneNote so as long as users of your app are already using OneNote you're fine to access their notes via our API. Just be sure not to DDOS us :)
If you can share, our community would love to hear about your app!
We are developing a web application using Microsoft Graph, where the signed in user can, Export all the calendar events to a third party calendar Application. After this initial export, we need to keep the exported data in sync with calendar changes via service app (a scheduled task running on server). This need to be a multi tenant application, as people from different organizations should be able to use this service.
Right now we did the authentication using OAuth 2.0 and OpenID Connect as described in this sample. Later we understood that the access token we get using this method cannot be used in the service app without user interaction. Considering our scenario what is the best way to achieve this?
I have read about App-only authorization method to do this. If we use this authentication method, the app need to be consented by a tenant administrator and the these applications are quite powerful in terms of what data they can access in the Office 365 organization. Considering we are developing a product used by different organizations, will it be feasible to use this method?
To use the client credentials OAuth2.0 flow (aka "App-only" or service account access depending on who's documentation you're reading) the admin for each tenancy will need to specify which scopes your daemon process can have for users in their tenancy. The end users can't give these scoping rights to your code themselves (as far as I know at least).
One thing to watch out for is that currently Graph API doesn't allow you to mess about with calendars that are attached to Office 365 Groups if you're using the client credentials flow. This is a pain for us, so we've raised it as an issue that needs fixing in the Office 365 feedback system. if that's an issue for you or anyone else, please throw a few votes at it so that it gets more attention at Microsoft. :-)
I'd like to be able to access a user's iCal and create events from my server, is this possible, preferably with some kind of OAuth2 setup like with Google Calendar? If so where can I find documentation on the API?
Unfortunately no. There is currently no OAuth whatsoever for iCloud. However, there are two solutions to consider:
Ask the user for their AppleID and password and store it on your server (not recommended for security reasons). This will allow access to EVERYTHING the user has enabled on their account; even the ability to log in and purchase content - thus the security issue. But it will give you direct access to iCal.
Ask the user for access to calendar through your app. Using EKEventStore requestAccessToEntityType: method you can gain access to the users local calendar. You could batch those events and send them to your server. You can find information on how to access calendar here.
It is possible. iCloud supports CalDAV on caldav.icloud.com, and that quite well. It allows you to create, modify and delete events and tasks. Unfortunately you have to have the user's credentials for this though.
I'm creating a simple iPhone app. The basic premise is that the app will display some data (That I provide online) on the application. The data changes over time, so the app has to draw the data from online and display it. I don't have a significant programming background so I don't want to use my own server.
Thus, I thought it would be significantly easier to just put the data into some documents on a Google account and then access them programmatically via the Google Drive API. I could then update the data in my Drive account and it would get updated in the application. The key here is that I am ONLY accessing ONE account that I own MYSELF. The users' accounts are not being accessed. Therefore the goal is to never have to log in manually. It should all happen behind the scenes, aka, it should look like a server, not a google doc.
With this in mind, it doesn't make sense to show the Google Accounts sign-in page to my users as the standard OAuth2.0 tutorial shows here:https://developers.google.com/drive/quickstart-ios#step_1_enable_the_drive_api
I should be able to access my own data by somehow hardcoding in my username, password etc. Google agrees here: https://developers.google.com/drive/service-accounts#use_regular_google_accounts_as_application-owned_accounts
The above link mentions a "refresh token" that I'm supposed to save. However, I have no idea how to build and save that token, or even for that matter, where to find it.
I've gone through both the basic tutorial and the Dr. Edit Tutorial for iOS, but they both assume that the application is accessing USER accounts not application-owned accounts.
I'm not asking for someone to write the code for me (though tidbits are nice), but if you can point me to a step-by-step guide or related sample code that would help me get started that would be awesome. I'll even come back and post the code that I use!
EDIT: Since I realized that the Google Drive API wasn't something I could use for what I am trying to do, I eventually found Parse which is an awesome tool that handles all the server backend for me and is free at the basic level.
Google APIs objective-C client library doesn't support service (application-owned) accounts, because they are supposed to be used by a server-side apps, instead of clients -- you shouldn't be distributing your private key as a part of an app.
If you would like to distribute content from a service account, maybe you should write a server leg to do the authentication and pass clients credentials in a secure way for them to talk to the API on the behalf of the service account. Or, use Web publishing to make documents universally accessible without authorization and authentication if privacy is not a concern.
I'm trying to work out the best architecture for a couple of apps I'm developing.
In both apps I want to utilise google/twitter/LinkedIn/etc to provide authentication of a users identity. The app is composed of an iOS app which has an option to send data to a server which I'm writing in node.js.
I want to utilise either OAuth or OpenId to handle identifying a user against the above servers so that I don't have to put in an authentication system of my own. In other words, allowing users to re-use their ids when choosing to upload data.
I should also note that apart from identifying a user, obtaining a name and email address, I have not intention of using any of their APIs at this time.
I think I have two options:
Place the Authorisation code in the iOS client and transmit some sort of key to the server with the data which it can then verify.
Keep the iOS client fairly dumb, and handle authorisation from the node server.
I'd probably prefer the second option because it means I could centralise authentication and be able to support a web site as well. That's my current theory.
Can anyone who has done something like this give me some pointers as to the pros and cons, OAuth or OpenId, or links to some examples?
In our previous app we opted for a combination of the two approaches. We wanted to centralize our user data on our server in the event we needed to make future API calls on those services. We also wanted the native oAuth experience for the user on the client. Ie: on Android and iOS, the developer can have single sign-on / authorization run through the native Facebook app (if available), vs. popping-up a webview that serves the 'Approve' dialog. It's a better user experience in my opinion. Also for Twitter, the oAuth process may require a PIN code to be entered in the callback which should probably be handled on the client side.
You can pass the access token retrieved by the client to the server for storage and later use if you intend on making additional API calls on these services, provided you expect the token to be long-lived (ie: offline-access permission on FB).
In any case this is mostly a user experience decision.