Hjelp til å få design mest mulig "riktig"

[GrinJe]

Hei.

 

Holder på med en prosjekt der jeg lager timeregistrering verktøy for mindre bedrifter. Bruker MySQL som database i prosjektet.

 

Jeg skal ha en form for login på denne løsningen. Lurer derfor på hva som er beste løsningen med tanke på tabeller for bruker osv,

 

Jeg har allerede en employee tabell (standard data om en ansatt) og en employee_info tabell (ekstra info om en ansatt). Planen frem til nå var å bruke employee nummer og ha passord lagret i employee_info. Har begynt å tenke at jeg kanskje burde lage en egen user database som er beregnet kun for innlogging og binde denne opp mot employee.

 

Hva er best practice for sånt?

 

 

[quantum]

Best practice er veldig varierende med miljøet applikasjonen skal kjøre i, ofte fins brukerne fra før av i en eller annen katalog, AD, LDAP eller lignende, og appen skal kanskje til og med kjøre under et felles SSO-system. Hvis dette skal brukes i mange ulike småbedrifter tipper jeg du vil finne at lister over ansatte/brukere finnes i mange ulike systemer (lønnssystemer, excelark, og oppover) og utfordringen din blir å integrere deg mot disse på et fornuftig vis.

 

Generelt er det kanskje fornuftig å skille mellom "bruker" og "ansatt", siden man kan se for seg andre typer brukere enn ansatte, f.eks. konsulenter ... men kanskje ikke i et timeregistreringssystem for ansatte? Her blir det spørsmål om tiltenkt funksjonalitet, nå og senere. Sett fra "logisk nivå" eller "domenenivå" kan du godt gjøre det enkelt og droppe "user" i første omgang, og hellet utvide senere ved behov. Da kan du bruke flere timer i starten til å kode funksjonalitet som faktisk er reelt nyttig med en gang. Men teknisk/arkitekturmessig kan det gi mening med et User-domeneobjekt som representerer en "person" i bedrfiten, en ansatt, en innleid konsulent osv. som du skal knytte din ansatt-informasjon mot. Denne brukeren trenger du ikke lagre i databasen din, men isteden bør du lage et User integrasjons-api som lar applikasjonen din autentisere brukerne mot ulike kataloger/kilder. Slike løsninger fins allerede i form av rammeverk som f.eks. Spring Security.

 

Skal du lagre passord i databasen, f.eks. når det ikke fins noen LDAP å autentisere mot og du velger å implementere dette selv, så må passordet være kryptert.

 

Spm. til slutt - hvorfor har du delt opp i employee og employee_info? Hvilken plattform skal løsningen kjøre på?

Endret 4. august 2014 av quantum

[GrinJe]

Hei.

 

Takker for flott og utfyllende tilbakemelding. Hovedgrunnen til å dele opp var for å ha en tabell med generell info og en annen med sensitiv info. Ville også holde selve tabellene så små som mulig for å enkelt kunne ha oversikt. Usikker på om det har noe hensikt, men når jeg lagde strukturen tenkte jeg at det kanskje var smart.

 

Jeg sikter mot mindre bedrifter som ikke nødvendigvis har så mange IT system fra før, derfor vil jeg nok måtte ha alt i min løsning og eventuelt tilby integrering dersom noen ønsker dette.

 

Mest sannsynlig blir dette kjørt på one.com løsning siden det er snakk om små bedrifter og liten mengde data.

[quantum]

one.com er en hostingleverandør og ikke en plattform. hvis det var ment som svar på spørsmålet :-) gjetter plattformen dermed er LAMP ...

 

jeg tror det første problemet du møter med dette er knytta til "sensitiv info" som du sier, dette vil bedrifter være skeptiske til å ha liggende på webhotell. Dersom du kun forholder deg til ansattnummer, og ikke har lagret noe annet som kan identifisere personer, og lar den knytningen foregå innad i bedriften, behøver de kanskje ikke være så skeptiske. Samtidig setter jo dette begrensninger.

 

når applikasjonen kjører på et webhotell blir nok også integrasjon med evt. ldapkatalog eller lignende mindre aktuelt og du må basere deg på egen brukerdatabase.

Endret 4. august 2014 av quantum

[GrinJe]

Hei og takk for svar.

 

Ja i første omgang blir det en enkel løsning. Dersom dette "slår ann" og flere blir interessert kan det være en idee å leie egen server og hoste der i stede.

 

Vi kan jo eventuelt bruke en form av hash (bcrypt) til de virkelige sensitive opplysningene. Dette vil i hvert fall skape en viss form for sikkerhet.

 

Enig i at integrasjoner blir vanskelig med one.com sin løsning. Men man kunne eventuelt validere brukere data mot en annen database eller ha integrasjon mot min database i form av stored procedures som en annen integrasjon på utsiden bruker.