Alessandro Del Sole's Blog

{ A programming space about Microsoft® .NET® }
posts - 1909, comments - 2047, trackbacks - 352

My Links

News

Your host

This is me! Questo spazio è dedicato a Microsoft® .NET®, di cui sono molto appassionato :-)

Cookie e Privacy

Microsoft MVP

My MVP Profile

Microsoft Certified Professional

Microsoft Specialist

Xamarin Certified Mobile Developer

Il mio libro su VB 2015!

Pre-ordina il mio libro su VB 2015 Pre-ordina il mio libro "Visual Basic 2015 Unleashed". Clicca sulla copertina per informazioni!

Il mio libro su WPF 4.5.1!

Clicca sulla copertina per informazioni! E' uscito il mio libro "Programmare con WPF 4.5.1". Clicca sulla copertina per informazioni!

These postings are provided 'AS IS' for entertainment purposes only with absolutely no warranty expressed or implied and confer no rights.
If you're not an Italian user, please visit my English blog

Le vostre visite

I'm a VB!

Guarda la mia intervista a Seattle

Follow me on Twitter!

Altri spazi

GitHub
I miei progetti open-source su GitHub

Article Categories

Archives

Post Categories

Image Galleries

Privacy Policy

Permission Elevation in LightSwitch

Come sapete, in LightSwitch è possibile impostare permessi per l'accesso da parte di ruoli e utenti solo alle risorse specificate e sapete anche come questo sia semplicissimo; da designer si definiscono i permessi, da codice si controllano tali permessi tramite una singola (di solito) riga di codice.

Beth Massi ha realizzato questo bel video qui, da cui potete imparare tutte le caratteristiche dell'Access Control.

C'è anche un'altra caratteristica meno nota, chiamata Permission Elevation che permette di elevare i permessi per un determinato utente da codice in talune circostanze.

Per esempio (leggi bene: esempio didattico ), immaginiamo di avere il ruolo del Responsabile delle Vendite. Gli utenti appartenenti a questo ruolo avranno la possibilità di creare, visualizzare, modificare, eliminare ordini, più altri permessi sulle tabelle dei clienti.

Supponiamo che esista un altro ruolo, quello degli Agenti per le Vendite. Questi potrebbero (siamo in un esempio ovviamente) avere accesso solo all'elenco di ordini che dovranno evadere, ma non avranno la possibilità di crearne di nuovi.

Il problema è che a un certo punto il responsabile delle vendite andrà in ferie e dovrà delegare qualcuno degli agenti all'inserimento. Chiaramente non è possibile assegnare l'utente Agente al ruolo Responsabili, per evitare che abbia troppi permessi (es. su altre tabelle oltre gli ordini). Come si può fare?

Innanzitutto si controllano i permessi lato UI per accedere allo screen di inserimento dell'ordine, ipotizzando che lo screen si chiami CreateNewOrder e che la permission sia stata definita come Can_Add_Orders:

        Private Sub CreateNewOrder_CanRun(ByRef result As Boolean)
            If Me.User.HasPermission(Can_Add_Orders) Or Application.Current.User.Name = "Giuseppe" Then
                result = True
            Else
                result = False
            End If
        End Sub

Questo, però, non è affatto sufficiente. Infatti si limita a rendere visibile o meno lo screen all'utente loggato se ha i permessi, ma il tentativo di salvataggio fallirà (ovviamente). Quindi è necessario elevare i permessi dell'utente loggato se risponde ai requisiti.

La permission elevation viene eseguita solo come codice server, quindi nell'ApplicationData. Accedendo a questa classe, si può gestire il metodo SaveChanges_Executing in questo modo:

        Private Sub SaveChanges_Executing()
            If Application.Current.User.Name = "Giuseppe" Then
                Application.Current.User.AddPermissions(Permissions.Can_Add_Orders)
            End If
        End Sub

In sostanza, quando viene premuto il pulsante di salvataggio il codice verifica l'utente loggato e gli assegna, tramite il metodo AddPermissions, l'autorizzazione richiesta al salvataggio. Alcune note importanti sulla permission elevation:

  • può essere aggiunta solo nei metodi Inserting, Inserted, Updating, Updated, Deleting, Deleted a livello di tabella poi SaveChanges_Executing, SaveChanges_Executed
  • fuori dai casi sopra citati, viene sollevata una InvalidOperationException
  • Nei metodi a livello di tabella (Inserting, Updating, ecc.) i permessi vanno revocati a mano tramite invocazione del metodo RemovePermissions
  • Nei metodi di salvataggio non è necessario revocare i permessi a mano, poiché vengono revocati al termine della save pipeline
  • Sia AddPermissions che RemovePermissions ricevono come argomento un array di stringhe, ognuna delle quali punta a una delle costanti che rappresentano i permessi, definite da designer. Esiste anche un argomento chiamato AllPermissions usato (giammai! ) per garantire o revocare tutti i permessi disponibili

Alessandro

Print | posted on lunedì 3 ottobre 2011 02:25 | Filed Under [ Visual Basic Visual Studio LightSwitch ]

Powered by:
Powered By Subtext Powered By ASP.NET