CFIMAPOauth.cfc (11.3 KB)
OK, I had to rip a bunch of client-specific stuff out so apologies if I left any syntax errors, etc. This is the basic CFC I used to replace my client’s use of CFIMAP in their application. It only implemented what I needed, so it may or may not do what you need. This is what id does
- Downloads messages for a given user
- max records
- saves attachments with unique names in a folder of your choice with some filename cleanup
- returns the same query object that cfimap created so you can hopefully just drop it in
- deletes a single message by ID (passed as a new column called
graphID)
So in order to use this you need to log into your Azure console and create a new oauth application with a similar flow to creating a facebook or twitter app. But unlike the typical Oauth flow used for SSO where a human user bounces through MFA, you set up an application using “client credentials”. This app will be able to read the E-mails of any user, but you’ll need to assign those permissions to the app.
Here’s a link to help with that part:
Once you’ve set up your app
- enter your tendant ID into the CFC
- enter your client ID to the CFC
- provide your client secret as an env var or java system prop. You can hardcode it into the CFC but I DON’T RECOMMAND IT since it’s like a super powerful password which would give anyone access to every E-mail address in your tenant.
There are a few other assumptions my CFC makes
- it will be created by WireBox
- you will have the Hyper module also installed
- Logbox will be available (comes via WireBox)
If you aren’t using those, that’s a darn shame, but you can easily refactor the code to work around it.
- Manually create the CFC and place it in the application scope to make it a singleton
- manually call the onDIComplete method once after creation to generate the initial access token
- Replace the Hyper calls with naked CFHTTP calls and do the work of deserializing the JSON yourself
- Replace the LogBox calls with some sort of manual logging
It’s also worth noting, there’s nothing preventing you from using an access token from a single sign on flow here if you are making a physical human go through the SSO flow and generate their own token. You’d need to rework the auth flow, but all the actual GraphAPI calls would work the same so long as that user’s token had the correct permissions.
Good luck!