È SPContext.Current suppone che sia nullo in servizio WCF personalizzato?

Question

Ecco lo scenario:

• servizio WCF personalizzato implementato in SharePoint 2010
• Il sito utilizza l'autenticazione reclami basati (FBA, NTLM)
• .svc viene distribuito al ISAPI nell'alveare
• Il servizio è configurato utilizzando fabbrica di servizio personalizzato
• Servizio viene chiamato dal browser utilizzando AJAX
• Sono in grado di colpire il servizio più che bene; il servizio è attivo e accettare richieste

Ecco il problema: SPContext.Current è sempre null. So che ci sono varie tecniche per "falso" uno SPContext o, ovviamente, per creare la SPSite e SPWeb manualmente, ma dovrebbe lo SPContext.Current essere nullo nei servizi WCF personalizzati quando si utilizza l'autenticazione di richieste basate ? O mi sono perso un qualche passo?

Non ho mai incontrato questo problema con l'autenticazione in modalità classica così mi chiedo se questo è solo qualcosa di particolare da autenticazione WCF + SharePoint + reclami basati e se ci sono possibili soluzioni alternative.

Grazie per qualsiasi visione!

- Chuck

Answer 1

Arrrrrgh! Finalmente capito dopo che pasticciano con questo per una buona giornata.

Voglio lasciare questo qui solo nel caso qualcuno corre altro nello stesso problema.

Quando mi iscrivo l'endpoint Javascript, io uso l'URL completo del servizio.

Quindi, se la radice del mio sito e ':

http://mydomain.com/sites/site1

mi iscrivo presso:

http://mydomain.com/sites/site1/_vti_bin/myservicedir/myservice.svc/js

Questo è tutto bene e bene. Quando la richiesta viene fatta per recuperare gli stub Javascript, posso vedere in violinista che la richiesta va a:

/sites/site1/_vti_bin/myservicedir/myservice.svc/js

Tuttavia, ho notato solo ora (finalmente, dopo a fissare per ore ..........) che quando faccio una chiamata a un metodo di servizio, l'URL viene tagliato fuori a:

/_vti_bin/myservicedir/myservice.svc/MethodName

Così la mia SPContext è sempre null poiché non v'è alcun contesto sito specificato nella URL.

Guardando gli stub Javascript da SharePoint, ho potuto vedere che la chiamata a set_path() stava usando l'URL tritato. Abbastanza semplice per risolvere chiamando di nuovo set_path() con il percorso corretto.