Hi Mr Connolly,

It is Pedro, from same development team as Carlos.

We know version 7.4.2 is almost "on the streets" and believe that we understand the phases that something like this have to go trough to be validated before going to release.

But as Joe himself and Will Morgenweck claim in one of the latest video explaining version, 7.4.2 aims to be a "really stable version" before the next big thing. And be that version a enough stable one for generations to last (we all know the problems that firms are having with product updates)

So, let me ask, how comes that a correction (and ours is indeed a correction, and not new features) that solve a long lasting problem as it is the impossibility to authority against LinkedIN, or lack of support of authorizations against other OAuth providers that required headers are not part of this "made to last" version ?

All we are asking is to give a second thought, check the lines that are modified in the core files (just very very few ones) and thing if they are better inside 7.4.2 version, or delay them for end of the year

Just counted, one pull changes two lines on OAuthClientBase.cs,and one line on the SpecificClient.cs , and the other one, eight lines on a single if on the same OAuthClientBase.cs

That would take minutes to review, and plenty hours saved for users.

Br,
Pedro.P.Grande

Hi Cathal,

first of all, thanks for the consideration,

We were not aware of the development times being so closed/strict , and we say really sorry for that.

We have made as you request, one PULLrequest with all the changes affecting the OAuthClientBase.cs, and only this, now only one file and few lines are affected:

https://github.com/dnnsoftware/Dnn.Platform/pull/606

More over, we have build it in a way so no changes are necessary on the SpecificClients.cs, and only those that declared the variables will modify the behaviour

On lines 141 and 146, the call to the new variables

On lines 363 to 369, the build up of the authorization header in case the corresponding variable is filled, otherwise, code just runs as usual.

On lines 744 to 746, the conditional to take an alternative AccessToken  only in case is provided, otherwise, same the same, code just runs as usual.

Tested with all four standard Specific Authorization providers, and our own developed ones for LinkedIN, FiWare and so on

We understand the exceptionalness  of this request being out of time, and again, we excuse ourselves for that, we will be more 

Integrating this request on DNN will provide, AFAWK, to have an stable and definitive DotNetNuke.dll for all authorization providers, and as you say "people don't feel forced to move to the new major branch quickly i.e. 7.4.2 users should not feel compelled to upgrade to 8.0.0 to get a showstopper fixed ", we are aware that not every developer working with DNN is taking the time or is willing to recompile the most central DLL.

Said that, we trust in your criteria will be best for all DNN users and the community. And so, agree with your decisions.

Best regards,

Pedro, and Carlos