În cele mai multe scenarii, nu puteți utiliza termeni simpli, cum ar fi AccessToken, ca cheia cache, după cum este necesar suprastructura pentru a stoca token-uri unice pentru fiecare utilizator și fermă SharePoint sau zona de client. Dacă add-in utilizează un flux de marcaj de context. SharePoint oferă o cheie specială pentru CacheKey. care pot fi folosite pentru a face distincția între marcatorii cache. Această secțiune descrie problemele și modul de rezolvare a acestora, în cazul în care programul nu folosește fluxul de marcatori de context.
Cachingul indicativului de acces în starea sesiunii este potrivit pentru majoritatea scenariilor. În cazul în care de la distanță aplicația web are acces la alte servicii care utilizează protocolul OAuth (în plus față de SharePoint), precum și diverse token-uri de securitate în cache-uri de stat sesiune, utilizează chei diferite cache pentru markeri. De exemplu, în loc de a folosi AccessToken SharePoint_AccessToken, Facebook_AccessToken, SAP_Gateway_AccessToken. (Dacă nu utilizați starea sesiunii sau altă metodă de cache care împarte automat cache-urile tuturor utilizatorilor, va trebui, de asemenea, să asociați cheile cu fiecare utilizator.)
Aplicația poate accesa mai multe ferme sau zone ale clientului SharePoint. În acest caz, utilizați domeniul SharePoint ca parte a cheii cache-ului principal al aplicației ("SharePoint_<мой_домен> .sharepoint.com_AccessToken ") sau o zonă de exploatație sau client (" SharePoint_
Dacă memoria cache de interconexiune pe care o utilizați utilizează, de asemenea, mai multe aplicații, cheile cache-ului trebuie să fie mapate către aplicații, utilizatori și zone SharePoint. Cheia cache furnizată în jetonul de context este unică pentru fiecare aplicație, utilizator și domeniul de aplicare SharePoint.
În cele din urmă, dacă add-on-ul dvs. efectuează apeluri SharePoint, atât cu permisiunile de verificare a aplicațiilor, cât și cu permisiunile utilizatorilor și permisiunilor suplimentare, acestea vor avea două jetoane de acces diferite. Pentru că aveți nevoie de chei de memorie cache diferite. După ce ați determinat cheia principală a cache-ului, adăugați doar "_add-in-only" (numai add-in) sau "_add-in + user" (add-in și utilizator).
Nu este sigur de a stoca tokenul de acces într-un modul cookie. Este mai bine să evitați transmiterea tokenului de acces prin browser.
Transmiterea jetonului de acces la sistemele de servere
Procesarea jetoanelor de acces expirat
Exemple de jetoane de acces
Politica pentru utilizator și add-in
Zona SharePoint este GUID a zonei client client SharePoint Online sau a fermei locale SharePoint la care accesează tokenul de acces. Acest GUID acționează ca identificator de zonă pentru editorul token, în acest caz serviciile Azure ACS.
Abreviere de la "emitent" (editor). Reprezintă subiectul care a creat jetonul. Format: GUID al editorului @ GUID al domeniului SharePoint.
Identificatorul unic al utilizatorului pentru care a fost emis un jeton. Formatul depinde de furnizorul de identitate. În acest exemplu, furnizorul este Microsoft Online. Dacă era un serviciu Active Directory, ID-ul ar arăta astfel: "s-1-5-21-2127521184-1604012920-1887927527-415149".
Subiectul care încearcă să acceseze ferma sau zona clientului SharePoint. Format: ID-ul clientului aplicației este domeniul de aplicare @ SharePoint.
Numele unic al furnizorului de identitate înregistrat la Autoritatea pentru Numere Atribuite prin Internet (IANA).
Pentru add-on-urile instalate în SharePoint Online, valoarea se potrivește, de obicei, cu cea specificată în acest exemplu.
Pentru programele de completare instalate în ferma locală, acesta este de obicei un furnizor de identitate locală, de exemplu "urn: office: idp: activedirectory".
Politică numai pentru add-in
Verificați marcatorul de context cu ajutorul secretului clientului de completare.
Cachearea semnului de context sau extragerea tokenului de actualizare sau a altor elemente din acesta și cache-ul separat al acestora.
Utilizați tokenul de actualizare și alte date pentru a solicita tokenul de acces din serviciul de control al accesului și apoi memorați-l în cache.
Salvați cheia CacheKey din simbolul context.
Primele două sarcini sunt importante pentru a fi realizate înainte ca utilizatorul să navigheze către o altă pagină sau să actualizeze pagina curentă, altfel tokenul va fi pierdut. De exemplu, într-o aplicație de formular web ASP.NET, aceste sarcini ar trebui să fie efectuate utilizând metoda Page_Load (în codul de stare, reprezentat de blocul care este executat dacă cererea nu este trecută înapoi). Într-o aplicație MVC ASP.NET, trebuie să efectuați aceste activități utilizând metoda implicită a controlerului.
Dacă utilizați cod, mostre de cod gestionat pentru unele dintre sarcinile prezentate în fișiere SharePointContext și TokenHelper (extensie CS sau VB), care sunt incluse în Microsoft Office Developer Tools pentru Visual Studio. Trebuie doar să efectuați apeluri simple către membrii clasei TokenHelper. De exemplu, codul dvs. poate gestiona prima sarcină cu o singură linie:
Caching un marker de context sau părți din acesta
Puteți cache întregul simbol context sau numai părți din acesta în memoria server sau client. De exemplu, tokenul de actualizare inclus în acesta și alte elemente, prin care codul primește token-uri de acces. Pentru a face lucrurile mai ușoare, acest articol presupune că cacheți întregul marker de context.
Amintiți-vă din nou, deoarece acest lucru este foarte important: nu utilizați cache-ul pe partea clientului pentru jetonul de acces. Poate fi folosit doar pentru un marker de context.
Opțiunile de cache din partea serverului sunt aceleași cu cele listate mai sus pentru jetonul de acces. Opțiunile de la client includ, de asemenea, un câmp cookie și un câmp ascuns în pagina HTML. În plus, puteți stoca marcajul de context în memoria cache a sesiunii și tasta CacheKey. pe partea clientului.
Dacă aplicația accesează SharePoint după terminarea sesiunii, nu se poate utiliza nici caching-ul sesiunii, nici cache-ul pe partea clientului. Acest lucru se datorează faptului că aplicația trebuie să aibă acces la tokenul de actualizare, în cazul în care tokenul de acces inițial expiră în timpul lucrului după sesiune. În acest scenariu, aveți nevoie de o memorie cache stabilă (inter-sesiune) care să partajeze mai mulți utilizatori, zone SharePoint sau aplicații. Deoarece codul trebuie să utilizeze chei de memorie care diferențiază utilizatorii, zonele și aplicațiile SharePoint, după cum este descris mai sus, în secțiunea Caching Cache de acces. Pentru a face acest lucru, puteți utiliza o cheie specială de memorie cache din marcajul de context, precum și simbolul de acces. (Consultați Înțelegerea cheii memoriei cache de mai jos.)
Conceptul de cheie de memorie cache
Cheia cache-ului este un șir opac care este unic pentru combinația dintre utilizator, editorul de nume de utilizator, farmul de completare și SharePoint sau clientul SharePoint Online. Următoarea este forma sa înainte de criptare, în cazul în care domeniul de aplicare este GUID a fermei locale SharePoint sau a zonei client SharePoint Online.
Nume_ID_ID + "," + Nume_proprietar_proprietar + "," + Application_ID + "," + domeniu
Deoarece, printr-o cheie cache, o aplicație poate să cacheze mai multe elemente într-o singură memorie cache, cum ar fi un simbol de acces și un jeton context, cheia cache-ului ar trebui utilizată ca bază. Dacă este necesar, puteți adăuga o linie specifică la începutul sau la sfârșit, de exemplu, AccessToken sau ContextToken, pentru a forma cheia completă a memoriei cache. O altă opțiune este să creați o clasă cu proprietăți pentru diferitele elemente pe care doriți să le arhivați, apoi să memorați în cache un obiect de acest tip. Există oa treia opțiune. în cazul în care utilizați baza de date ca o memorie cache. Aceasta înseamnă utilizarea unui tabel cu o coloană CacheKey și a unor coloane suplimentare pentru elementele memorate în cache (AccessToken, ContextToken, etc.).
Desigur, aplicația nu ar trebui să utilizeze o singură memorie cache pentru toate operațiile de cache. În mod obișnuit, tokenul de acces este stocat în memoria cache-ului sesiunii, semnul de context (sau jetonul de actualizare din acesta) este în baza de date, iar cheia CacheKey este în cookie.
Obținerea unui jeton de acces folosind markerul de context
Pentru a obține un jeton de acces, aplicația trimite o cerere direct serviciului de control al accesului. Solicitarea include trei fragmente de date extrase din marcatorul de context, precum și alte informații:
GUID-ul subiectului aplicației în SharePoint.
Farmerama SharePoint GUID sau zona de client SharePoint Online pe care add-on-ul vrea să-l acceseze.
O aplicație poate obține clientul SharePoint sau zona fermei în timpul executării, în loc să-l extragă din marcatorul de context. Dacă utilizați cod gestionat, există metoda TokenHelper.GetRealmFromTargetUrl pentru a obține domeniul de aplicare. Valoarea trebuie să fie stocată în memoria cache, astfel încât codul să nu se repete din nou pe rețea pentru a-l primi.
Obținerea unui nou indicator de context
CLIENT_ID. Client ID SharePoint Add-in.
Exemplu de marcator de context
Aprobări aud. iss. nbf și exp sunt aceleași ca în jetonul de acces (prezentat mai sus). Aprobări appctxsender. appctx. CacheKey. SecurityTokenServiceUri. refreshtoken și isbrowserhostedapp sunt descrise în tabelul de mai jos.
Tabelul 3. Afirmațiile contextualizării și informațiile despre acestea
Restricționarea accesului numai pentru utilizatorii SharePoint utilizând markerul de context
Tokenul de actualizare este inclus în tokenul de context pe care serviciul SharePoint îl publică în aplicația Web când pornește. Jetonul de upgrade este criptat și add-in-ul SharePoint nu îl poate decripta. Codul folosește acesta și alte date pentru a obține un nou simbol de acces după expirarea tokenului de acces curent. Cu ajutorul acestuia, puteți obține și primul simbol de acces în fluxul de marcaj de context. (În momentul acestei scrieri, durata de viață a jetonului de actualizare eliberat de serviciul de control al accesului pentru SharePoint era de 6 luni, dar acest lucru s-ar fi putut schimba.)
Din moment ce tokenul de acces este valabil doar câteva ore (acum este de 12) și utilizatorul primește unul nou de fiecare dată când este lansat SharePoint Add-in în SharePoint, tokenul de actualizare este necesar numai în astfel de scenarii:
Utilizatorii au deschis sesiuni de extensii lungi în care efectuează apeluri SharePoint în câteva ore (mai mult de 12) după pornire.
Design-ul add-in permite utilizatorilor să-și programeze accesul la SharePoint după încheierea sesiunii.
Trimiteți-le prietenilor: