Domanda

Ho un sito SharePoint 2013 basato su attestazioni che utilizza una pagina di accesso personalizzata e supporta più metodi di autenticazione.In generale, le cose stanno funzionando come previsto.Gli utenti possono accedere, accedere ai contenuti, ottenere le attestazioni basate sui ruoli appropriate e così via.

Tuttavia, quando gli utenti si connettono utilizzando Excel per aggiornare una query, viene visualizzata la pagina di accesso, ma in realtà sta cercando di portarli a error.aspx.Dopo alcune indagini, ciò sembra accadere quando l'utente non ha ancora effettuato l'accesso al sito, quindi non dispone di un FedAuth token-questo ha senso in qualche modo perché il punto in cui Excel è in grado di mostrare la pagina di accesso è quello di consentire all'utente di accedere, giusto?Ma non vedo dove il error.aspx il reindirizzamento proviene da, e il registro ULS mostra solo la richiesta di error.aspx, non la ragione per l'errore.

Posso riprodurre il problema nel mio ambiente di sviluppo, che consente non SSL, quindi è facile replicarlo da una sessione telnet:

Richiesta (sanitized):

OPTIONS http://fqdn.for.site.here/ HTTP/1.1
Host: fqdn.for.site.here

Risposta (sanitized):

HTTP/1.1 403 FORBIDDEN
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.0
X-SharePointHealthScore: 0
SPRequestGuid: 9a3d619c-124b-2027-0000-03f0e96e36ea
request-id: 9a3d619c-124b-2027-0000-03f0e96e36ea
X-Forms_Based_Auth_Required: http://fqdn.for.site.here/_layouts/15/Company/CustomLogon.aspx?ReturnUrl=/_layouts/15/error.aspx
X-Forms_Based_Auth_Return_Url: http://fqdn.for.site.here/_layouts/15/error.aspx
X-MSDAVEXT_Error: 917656; Access denied. Before opening files in this location, you must first browse to the web site and select the option to login automatically.
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4420
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Tue, 17 Dec 2013 17:48:58 GMT
Content-Length: 13

403 FORBIDDEN

Oltre a guardare il registro ULS, ho anche cercato di vedere se un modulo HTTP personalizzato sta interferendo (ce n'è uno in atto per sostituire la pagina di accesso negato poiché la capacità del 2013 di farlo "correttamente" è rotta), ma il bypass non sembra cambiare nulla.

Qualcuno ha un pensiero sul perché il mio primo accesso sta cercando di andare contro error.aspx- o cosa posso fare per cercare di rintracciarlo ulteriormente?

È stato utile?

Soluzione

Dopo molto più tempo e indagini sembra che questo sia un comportamento "normale".L'errore non ha molta importanza e viene buttato via come meglio posso dire;potrebbe anche non essere un vero errore nella vita reale.Sembra che i clienti dell'ufficio facciano alcune cose hackish per fare quello che fanno.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a sharepoint.stackexchange
scroll top