Recht Management über Bitmuster

[F.o.G.]

Rechte Management über Bitmuster

Hallo,

ich würde mich sehr freuen, wenn mir jemand Informationen zu bitweisen Berechnungen liefern könnte und am besten auch, wie man damit zum Beispiel die Rechtevergabe verwaltet. Das ganze wird in der PHPLib verwendet, aber irgendwie ist das dann doch sehr komplex....

Warum ich das frage? Wie läuft das normale Rechte Management ab? Man erstellt eine Perm Tabelle und legt dort für jedes zu vergebende Recht ein Feld an. Auf die Dauer wird das sehr viel und ich bin an einem Punkt angelangt, an dem ich mehr als 20 Rechte pro User vergeben muss.

Durch bitweise Berechnungen kann man das ganze auf 1 (!!) Feld begrenzen, das nur eine normale Dezimalzahl enthält. Es tritt also eine erhebliche Platzersparnis ein, die Datenbank kann schneller arbeiten .... aber man muss sich damit gut auskennen.

Ciao, F.o.G.

 

[melmager]

hm
20 rechte ist aber eine blöde zahl...
da ist longinteger angesagt
aber zu deiner Frage:
jedes bit hat eine wertigkeit (wie bei normalenzahlen auch)
ich mach mal ein 3 er beispiel:
001 entspricht 1 weil das rechtebit die wertigkeit 0 hat und
2 hoch 0 ist 1
das nächste hat
2 hoch 1 ist 2
next
2 hoch 2 ist 4
oder anders von rechts nach links verdoppelt sich immer der wert
sprich 1,2,4,8,16,32,64,128,256,1024 usw ....
ps bei dir sind es dann 2 hoch 19 *g* ganz links
so jetzt ordnet man jedem recht ein bit zu
zb die zahl 5 ist = 101 (1*4 + 0*2 + 1*1)
bedeutet du hast 2 rechte (welche auch immer du als prog legst ja fest was die bits zu sagen haben)
more info ? nur fragen smile
ev mal das tut zu chmod durchlesen da unix auch uber bits arbeitet
bei den rechten

und auswerten ?

einfach if($recht & 4) { # das dritte bit ist gesetzt

nachtrag WICHTIG:
ich habe nochmal nachgesehen und wie ich es mir dachte mit einer zahl kannst du leider nicht arbeiten, du musst 2 nehmen. Hintergrund:
php kann bei deiner anwendung nur maximal 2 hoch 14 als rechte bit
verwalten

 

[worki2k1]

Das System ist eigentlich recht einfach. Ich mach es folgendermaßen:

<?php
/* Definition der Rechte als Konstanten */
define ("PERM_DATEILESEN", 1 << 0);
define ("PERM_DATEISCHREIBEN", 1 << 1);
define ("PERM_DATEILOESCHEN", 1 << 2);

/* usw... */
?>

In der Datenbank speicherst du in einem Feld die Summe aller Rechte, die der Benutzer besitzt.

Um abzufragen ob der Benutzer ein bestimmtes Recht besitzt machst du folgendes:

<?php

// Angenommen in $permissions ist der Wert aus der Datenbank gespeichert:

if (PERM_DATEILESEN && $permissions)
{
  // Der Benutzer hat das Recht.
}

?>

Die einzige Schreibarbeit hat man beim Formular, wo man die Rechte einstellen kann. Aber da kann man sich ja auch Funktionen schreiben, die einem das erleichtern.

 

[Maximka]

@workaholic:
deine if-abfrage funktioniert?
muesste es nicht so sein?

if (PERM_DATEILESEN & $permissions) {}

 

[F.o.G.]

ok, super. das sieht ja schon ganz gut aus.

Zum Längenproblem: ich denke, ich werde die Rechte als Gruppen in mehreren Feldern anlegen. Bei 2 Feldern kann man so ja 28 Rechte definieren.

Eine andere Möglichkeit wäre ja, die Muster als VARCHAR zu speichern, ...Ich glaube auf die Dauer wird das zu langsam, als wenn man ein Integer Feld nimmt oder? mal abgesehen davon, dass dann die Platzersparnis dahin wäre.

Ok, ich danke erst mal für die Infos...

@maximka: hat er sicher nur verwechselt, du hast recht, dass ist nur ein &

In dem Zusammenhang fällt mir ein: was wird eher in diesem Term abgearbeitet: (2 & 3 != 0) ? Sieht PHP das so: ((2 & 3) != 0) oder so: (2 & (3 != 0)) ???

Ciao, F.o.G.

 

[melmager]

also ich behaupte mal integer ist schneller
auf jeden fall ist integer kleiner wie varchar (vom platzbedarf her)

integer = 2 byte
varchar = anzahl der char plus 1 byte

 

[JoelH]

Original geschrieben von F.o.G.

In dem Zusammenhang fällt mir ein: was wird eher in diesem Term abgearbeitet: (2 & 3 != 0) ? Sieht PHP das so: ((2 & 3) != 0) oder so: (2 & (3 != 0)) ???

Ciao, F.o.G.

logischerweise (2&3) != 0 denn != ist in diesem Fall ein Vergleichsoperator und kein logischer Operator.

 

[F.o.G.]

also ich weiß, dass man Bit operatoren und Vergleichsoperatoren mischen kann. Bist du dir da hundertprozentig sicher?

Ich sollte das mal ausprobieren. Wenn man den Term so wie du verstehst, müsste das so lauten: ist das 2. Bit in 3 gesetzt? 011 -> ja, also 1, und 1 != 0, also kommt true (1) als Endergebnis raus. Wenn der Term aber anders verstanden wird, also der Vergleichsoperator zuerst abgearbeitet wird, kommt bei 3 != 0 auch wieder eine 1 raus, was aber zu 2 & 1 führt, was dann aber in 0 endet (das 2. Bit ist in 1 nicht gesetzt).

Ciao, F.o.G.

[after edit] Also nach einem Test kam raus, dass die Vergleichsoperatoren mehr wert sind und zuerst abgearbeitet werden[/after edit]

 

[Maximka]

aber wieso ueberhaupt der vergleich mit null?
man muss es ja garnicht vergleichen
denn false ist auch nur eine null

Ausserdem, schaden klammern, auch wenn sie redundant sind, nicht.
Man kann dann auch schneller erkennen was zuerst ausgewertet wird und ist sich auch sicher wie das mal gemeint war.

 

[JoelH]

hmm,

Zeichenketten-Operatoren

Operator-Rangfolge

Die Operator-Rangfolge legt fest, wie "eng" ein Operator zwei Ausdrücke miteinander verbindet. Zum Beispiel ist das Ergebnis des Ausdruckes 1 + 5 * 3 16 und nicht 18, da der Mulitiplikations-Operator ("*") in der Rangfolge höher steht als der Additions-Operator ("+"). Wenn nötig, können Sie Klammern setzen, um die Rangfolge der Operatoren zu beeinflussen. Zum Beispiel: (1 + 5) * 3 ergibt 18.

Die folgende Tabelle zeigt die Rangfolge der Operatoren, oben steht der Operator mit dem niedrigsten Rang.

Tabelle 11-1. Operator-Rangfolge

Associativity
Operator

links
,

links
or

links
xor

links
and

rechts
print

links
= += -= *= /= .= %= &= |= ^= ~= <<= >>=

links
? :

links
||

links
&&

links
|

links
^

links
&

keine Richtung
== != ===

keine Richtung
< <= > >=

links
<< >>

links
+ - .

links
* / %

rechts
! ~ ++ -- (int) (float) (string) (array) (object) @

rechts
[

keine Richtung
new

aus
http://de.php.net/manual/de/language.operators.php#language.operators.precedence