Jogosultság kezelés mezőszinten
 Sziasztok,
Olyasmi jogosultság renszert akarok csinálni, mint ami az iwiw -en van, ha egy adatlapot megnézek és attól függően látom az adatlap adatait, hogy tulaj mit állított be adott adathoz. Pl. email cím -> nem láthatom addig, amíg nem vagyok ismerőse...
A kérdésem/kérésem, hogy ezt hogyan lehet a legszebben és legszakszerűbben kivitelezni.
Nekem is van ötletem, csak nem vagyok benne biztos, hogy ez a megoldás.
Én arra gondoltam, hogy abban a táblában.. |

Ok, értem én, csak nem tudom elképzelni a hozzászólása alapján, hogy 80k felhasználója lenne, ha meg igen irigy vagyok... 
Esetleg nem tudnál ajánlani egy junior php fejlesztő állást Debrecenben? 
 |
Igen, lehet implementálni más protokollal is, de tcp/ip ip nélkül?
Igen, TCP/IP helyett mas transport szinten (vagy alatta) levo protokollal...  |
Szia
Csak a kedvedért megkerestem a HTTP/1.1 protokoll leírását.
RFC2616
Ezt írják: HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.
Igen, lehet implementálni más protokollal is, de tcp/ip ip nélkül?
Nem lennék a 1 abból a 80 000-ből.  |
Szia
SQL sort ír be a login mezőbe? Nem akarok okoskodni, de nem gondolod, hogy figyel ilyesmire az, aki egy új iwiw-et akar írni? :D
Egyébként meg ott a doctrine/propel meg még egyéb társaik és nem kell aggódni sql injection miatt.
Ja és már bevitelnél le kell tiltani minden SQL utasítást/parancsot/az adatbázisban használt mezőnevet.
Ezzel sem értek egyet. Egy prog.hu-nál ez vicces eredményre vezetne, nem gondolod? Szerintem inkább quote-olni kell mindent az adott db motornak megfelelően. De ha te így gondolod...
Ha nincs, mert rejti vagy ilyesmi, egyből destroy session, mert akkor tuti rosszban sántikál;)
Ugyan mutasd már meg, hogy lehet elérni, hogy ne jelenjen meg ip egy http kérés után! Szerinted hogy kapod meg a választ ip nélkül? Gondolati úton, vagy mi?  |
Sziasztok!
Ha a környezet PHP+MySQL A MySQL-ben InnoDB motor, mert az sem teljesen mindegy
Nem rossz gondolat a plusz mező, de a biztonságra is figyelni érdemes. Olyanokra gondoltál, hogy valaki a login mezőbe egyből egy sql sort ír be?
Loginhoz külön tábla, mindig és lehetőleg ne egyszerűen users-nek hívd a táblát. Ez alap. Lehetőleg logold is az eseményeket hozzá ezt is külön táblában.
Ha akarsz külön jelszó szinteket, akkor tegyél be egy flagmezőt, mondjuk 1 karakteres INT, ha nem elég VARCHAR is lehet, mert csak a szintazonosításhoz kell később. A mezőnevek minimum a logintáblában vagy máshogy usersben ID, azonosító, jelszó, flag. Persze ha még akarsz ezt-azt tehetsz hozzá, de ez már elég kell hogy legyen.
A PHP hozzá legalább sessiont használj hozzá, ha nincs meg a beléptetés értékben a true, ne legyen olyan php fájl, ami megnyitható! A GET használata meg egynesen tilos, csak POST. A Browserben ne nagyon jelenjen meg más az index.php -n kívül
Ja és már bevitelnél le kell tiltani minden SQL utasítást/parancsot/az adatbázisban használt mezőnevet. Ha véletlenül valaki mégis beírná, már mehet is a session destroy
Nekem működik rendszerem 80000-es felhasználó táborral és nem lassú Egyszerűen nem kell szétriggerelni az adatbázist és jól kell normalizálni, egy idő után majdnem mindig ugyanaz lesz főleg a login-hoz használt és log-hoz használt tábla
Ja a logban érdemes figyelni az IP-t is. Ha nincs, mert rejti vagy ilyesmi, egyből destroy session, mert akkor tuti rosszban sántikál;) Persze az ilyeneket vég nélkül lehetne még sorolni, de ez már elég az esetek 95%-ban.  |
Adatbázis szinten törekedj az egyszerűségre mert, ha sok user lesz és már pedig közösségi oldalt szeretnél gondolom. (csak minek megint egy?)
Akkor a bonyolult összetett adatbázis rendszerbe belefog halni az oldal, mert több száz ezres sornál is már haldokolni fog... :s
Ki szeretne fél percet várni 1-1 műveletre...
Jah, még annyi: Szerintem ha MySQL -t használsz: INT forma, 1 és 0-9 ig tudsz adni tulajdonságokat, amiket PHP -val már tudsz kezeleni...
Pl.:
0 = senki
1 = bartáok
2 = mindenki |
Szerintem felesleges külön táblát csinálni ennek az egésznek, csinálsz egy mezőt, azt annyi. Lekérik a profil oldalt kívülről, megnézed, hogy mi van a meződben, az alapján írod ki. Utána kesseled fájlba, és a következő alkalommal már a fájlból íratod ki. Felesleges túlkomplikálni az ilyesmit.
 |
Egy táblában tárolod a jogosultságokat. Minden rekord egy jogosultság. Az, hogy logikai szinten ez pontosan milyen adatterületre vonatkozik már üzleti logika szinten tudod befolyásolni.
ASP.NET c#: RoleProviderrel elkészíted a jogok felolvasását, lesz egy listád a felhasználó jogairól, és amikor az adott lapot töltöd akkor lehet tiltani az egész oldalt is ([PrincipalPermission(SecurityAction.Demand, Role = "JOGOSULTSAG", Authenticated = true)]
), lehet metódus szinten szabályozni (ua), és lehet blokkszinten is if (Roles.IsUserInRole("JOGOSULTSAG")) {...}
Egy másik táblában nyilván ott vannak a felhasználók, egy harmadik táblában meg összerendeled a felhasználókat a jogosultságokkal.
A jogosultságnál érdemes egy név mezőt és egy leíró mezőt is felvenni, amiben kifejtheted, hogy mire jogosítja fel a felhasználót ha hozzárendeled a jogot.
Természetesen felhasználó csoportot is lehet csinálni, jogosultság csoportot is, ezeknek is összerendelőket stb...
Én valahogy így csinálnám.  |
Ha kesobb ez biztosan nem fog tovabb bonyolodni
szerintem erre nem érdemes alapozni, mert lehet bonyolódni fog később a tábla szerkezet... 
 |
Nekem az 'jon le', hogy bizonyos mezokre plusz 1 bit informaciot kellene tárolni. Ha kesobb ez biztosan nem fog tovabb bonyolodni, akkor egy bit mezo boven eleg szerintem. (plusz a szerver meguszik egy join-t, ami minden egyes ilyen bit-et (checkbox-ot) minimum 64 bit-re 'tomorit' (id+index):p)
Persze ha nem tudni, hogy mit akar az ugyfel, akkor +tábla  |
Sziasztok,
Olyasmi jogosultság renszert akarok csinálni, mint ami az iwiw -en van, ha egy adatlapot megnézek és attól függően látom az adatlap adatait, hogy tulaj mit állított be adott adathoz. Pl. email cím -> nem láthatom addig, amíg nem vagyok ismerőse...
A kérdésem/kérésem, hogy ezt hogyan lehet a legszebben és legszakszerűbben kivitelezni.
Nekem is van ötletem, csak nem vagyok benne biztos, hogy ez a megoldás.
Én arra gondoltam, hogy abban a táblában, ahol a tárolva vannak a user adatai pl. email cím, akkor a tábla mező mellé felveszek még egy oszlopot.
Tehát:
| email | email_role_id |
| prog@prog.hu | 2 |
és lenne egy role táblám, amiben lennének a jogok:
| id | name | code |
| 1 | Mindenki | EVERYBODY |
| 2 | Senki | NOBODY |
...
.....
Vélemény? :)
Köszi előre is a segítséget! |
|