MS User Directory Plugin Issue


#1

I’m having a bit of trouble getting this plugin to work. I’ve followed the steps on Git. I login as a user with MS and give the app authority but when it returns to the site I get an error. I’ve removed the cflocation tag and replaced it with a dump of the arguments.stParam. The loginReturnURL is blank. Am I missing a step?

Sorry the line number below should say 38. I’ve been testing things :slight_smile:

Also if I try and login with my normal sysadmin account I get a ‘restricted’ box in yellow appear (see below).

image

image


#2

I have had this issue on one site is using HTTPS - I think a cookie was getting lost on redirect from http to https during login phase

Try this:

in your project extend farcry.plugins.googleud.packages.security.GoogleUserDirectory

and add

<cffunction name=“getRedirectURL” access=“public” output=“false” returntype=“string” hint=“Sets scheme and return sub-domain for BOB; for use with getAuthorisationURL and getRefreshToken”>

	<cfreturn “#protocol#://#cgi.http_host##application.url.webroot#/index.cfm?type=gudLogin&view=displayLogin” />

and in project copy webskin/gudLogin/displayLogin.cfm

and change cflocation to

<cflocation url=“#application.security.userdirectories.gud.getAuthorisationURL(clientID=application.fapi.getConfig(‘GUD’, ‘clientid’),redirectURL=‘#application.security.userdirectories.gud.getRedirectURL()#‘,scope=‘https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email’,state=‘’)#” addtoken=“false” />


#3

Thanks,
It’s certainly using https and proxing from nginx > apache > tomcat.
Your example is for the google UD so I’m hoping the solution is interchangeable. I’ll have a go in the morning.
Also I’m might try removing nginx from the equation and see if that helps.


#4

I think each plugin had the opposite issue; Google UD redirects to a hard coded http:// protocol, and Microsoft UD redirects to a hard coded https://.

I’ve just pushed commits to both plugins to correct this, so the protocol that is defined in the Environment configuration in the webtop should be respected (or this can be set with env vars in the case of Docker). That way you can still set it to HTTP for development if that’s convenient, while using HTTPS for production.

Hopefully you can just pull the latest commit on master and it’ll be resolved :slight_smile:


#5

Hi Guys,
Thanks for the replies. I managed to resolve the issue buy removing nginx out the the equation. :slight_smile: There must have been something lost during the proxying through all those webservers.
Cheers Phil


#6

I’ve noticed that it isn’t returning the refresh_token.
I found this https://stackoverflow.com/questions/43870554/microsoft-oauth2-authentication-not-returning-refresh-token
I changed the scope in the configuration and in the ms app console to user.read offline_access and now it returns the refresh token. But only for a current user. If I login for the first time an error gets thrown and no user is created.

key [OBJECTID] doesn't exist. The specific sequence of files included or processed is /srv/www/htdocs/farcry/plugins/microsoftud/packages/security/MicrosoftDirectory.cfc, line: 75"

Any suggestions?


#7

Looks like I’ve found the issue. The refresh token is over 1000 characters long.

query tag;lucee.runtime.exp.DatabaseException
Data truncation: Data too long for column 'refreshToken'

RefreshToken needs to be changed to longchar

<cfproperty ftLabel="Refresh Token" name="refreshToken" type="longchar" default="" />


#8

Ahhh, well spotted Phil :slight_smile: It seems the token size does vary across OAuth 2.0 implementations from vendors… Some are 255, some others are below 500, some are 1024, others could be larger.

I’ll patch it from string to longchar, thanks.