Skip to content
This repository has been archived by the owner. It is now read-only.

Provisioning Engine - Template extraction breaks on start on O365-Dedicated #615

Open
biste5 opened this issue Jun 8, 2016 · 5 comments
Open
Labels

Comments

@biste5
Copy link
Contributor

@biste5 biste5 commented Jun 8, 2016

Category

[x] Bug
[ ] Enhancement

Environment

[x] Office 365 / SharePoint Online -> O365-Dedicated
[ ] SharePoint 2016
[ ] SharePoint 2013

If SharePoint on-premises, what's exact CU version: Oct 2015 CU

Expected or Desired Behavior

I'm trying to run a site template extraction using PnP Provisioning Engine, via WebExtensions.GetProvisioningTemplate against a O365-D site (sub site), for which I am a Site Collection Administrator

Observed Behavior

It breaks pretty immediately when processing starts, for some internal error generating a WebException (403 - Forbidden), on ClientContextExtensions.ExecuteQueryImplementation called initially by WebExtensions.IsSubSite()

Steps to Reproduce

Run a template extraction WebExtensions.GetProvisioningTemplate, connecting to a O365-D site.

I haven't had the chance to debug where the issue occurs, but I think you guys are cloning the ClientContext somewhere, into a PnPClientContext, and probably not cloning WebRequestExecutor event handlers, which are important (needed) for connecting to 365-D.
Specifically, a working context on 365-D for me must have following:

context.ExecutingWebRequest += (sender, e) => { e.WebRequestExecutor.WebRequest.UserAgent = "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"; e.WebRequestExecutor.RequestHeaders.Add("X-FORMS_BASED_AUTH_ACCEPTED", "f"); };

If there would be a priority, for me, it would be High! :)
Thanks
Massimo

@biste5
Copy link
Contributor Author

@biste5 biste5 commented Aug 5, 2016

Based on a very insightful tip received from @jansenbe , and some positive tests done after wise, the issue is with PnPClientContext.Clone method implementation, more precisely where ExecutingWebRequest is processed and cloned only in case is trying instantiate a context without any credentials / authentication Line 109 = 116

It shouldn't hurt and be good to move that block outside the if branch (?)
Anyway I feel like it can be an impacting change, so needs to be tested with all different scenario: SP2013-2016-SPO, with and without Claims enabled, and with anonymous access.
I don't have myself all these environment easily available for tests.

Cheers, keen to hear your thoughts
Massimo

Loading

@nhadro
Copy link

@nhadro nhadro commented Dec 6, 2016

Did a resolution ever get implemented for this or did you find a work around? I am having the same issue but with an On-Premise instance with FBA and NTLM enabled.

Thanks,
Nate

Loading

@biste5
Copy link
Contributor Author

@biste5 biste5 commented Dec 6, 2016

The workaround is to compile your own binaries of PnPCore where you will have code block from L111 to L118 of PnPClientContext moved outside the conditional block

if (this.Credentials != null)
...
else
...

It's probably a good idea if you create a separate issue, marked for SP On-Prem. You can briefly describe your scenario and reference this one; with hope that will be adjusted in the official binaries

HTH
Massimo

Loading

@jansenbe
Copy link
Contributor

@jansenbe jansenbe commented Feb 3, 2017

This is indeed a bug in the clone method which impacts FBA scenarios in on-premises.

Loading

@biste5
Copy link
Contributor Author

@biste5 biste5 commented Feb 3, 2017

and 365-Dedicated (which uses 'claims' too), and Anonymous authentication (if someone ever tried to use that); as far as I know

Loading

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants