Propegation af custom brugerinfo til brug for programatic securit
Davsen
Jeg er for nyligt begyndt at rode med EJB og har fået lavet nogle simple applikationer med session beans, entity beans brugt fra en web-appliktation (bruger Jboss 3.2.3). Jeg vil nu gerne havde portet en gammel ting jeg har lavet i php, og prøver i den forbindelse at finde en smart måde at lave sikkerhedssystemet på.
"Problemet" er at jeg vil styre adgangen til nogle entity beans ud fra en række "custom" informationer om brugeren, fx postnummer. Jeg er altså nød til at brug programatic security og spørsmålet er så hvordan jeg smartest for den nødvendige information til rådighed i de session bean der styrer adgangen til entity beansne.
En løsning jeg har overvejet er at modellere hver bruger som en entity bean, og sætte serveren til at cashe et antal af disse beans. Jeg kan så i sessionbean kalde getPrincipal().getName() og finde brugerens entity bean og dermed få fat i de informationer jeg skal bruge til min authorisation. Jeg syntes bare det virker lidt tungt og meget upraktisk specialt hvis der ligger flere session beans efter hinanden i en eksekveringskæde og hver af dem skal tjekke brugerens rettigheder.
Så hvad mit spørgsmål går ud på er egentligt om det er den smarteste måde at gøre det på, eller I har andre forslag. Jeg håbede fx på at det var muligt at "ligge noget info ved" brugerens pincipal objekt så det automatisk blev progegeret med kaldet eller noget, men har ikke kunne finde ud af at gøre noget sådant.
Støv, fibre og metalliske partikler kan påvirke både uptime, levetid og driftssikkerhed. Derfor arbejder flere datacentre systematisk med contamination control.
Det er mest løsning 3 jeg hælder imod. Jeg simplificerede situationen lidt i min post for at det ikke skulle blive alt for rodet at læse. Ud over postnummer har jeg også nogle "access flags" som fx canEdit, canRead, canUpdate osv. Det bliver så endnu mere rodet af at der til forskellige typer data er forskellige handlinger ud over de der standard edit retigheder, fx kan køre de og de procedurer. Så samlet set er det rigtigt mange flags, der pt er implementeret som bit-flags i en int var for hver "certificat" (rettigheder til en bestemt type data). Det er derfor jeg er lidt forhippet på at få alle de her data med ud, og gerne skulle indlæse dem så lidt som overhovedet muligt da der ellers skal bruges mange db kald på kun det.
Man kan selvfølgeligt kalde ret fjollet at spilde tid på til vores brugsbelastning, men vil gerne gøre det på "den rigtige måde". Den oprindelige php app som jeg gerne vil erstatte bruges i en slags hobby-forening på nettet, og da der er mange komboer for hvem laver hvad og geografisk hvor, så er det nødvendigt med alle de har access flags, hvilket gør et role baseret approch meget upraktisk til detaljeret styring.
Vil meget gerne høre mere om hvordan det er du tænker en singleton løsning implemteret i en ejb server. Så vidt jeg har forstået må man ikke havde static fields i bean så jeg er ikke helt med på hvordan det skal gøres =) Den samlede data mængde for access dataen er temmeligt lille (kun omkring en 250 medlemmer/brugere pt) så det er da bestemt muligt at havde det hele indlæst.
At hente data fra en singleton er teknisk set ikke et static field d.v.s. at du får ikke warnings af din IDE.
Singleton har naturligvis samme problem som static field i EJB sammenhæng nemlig at app-servere gerne må bruge flere JVM'er og så er der mere end en instans af både static field og siingleton.
Men det er du formentlig ligeglad med. Forudsat at det er readonly data af begrænset størrelse, så læser du det op i en singleton (i constructor). hvis du på et tidspunkt deployer på en app-server som bruger flere JVM'er, så får du en kopi per JVM. Men det virker stadig helt fint. Og da der vel skal afsættes 200MB-2GB RAM per JVM alligevel så er overheadet nok ikke særligt stort. JBoss bruger iøvrigt kun 1 JVM per box.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
