Wie kann ich Checkboxen, Radiobuttons und Selectboxen anzeigen aber nicht ändern lassen?

[Klaus1]

Hallo,

wenn ich "normale" Input-Elemente vom Typ Text habe, kann ich diese mit dem Attribut readonly (bzw. readonly="readonly") für die Eingabe deaktivieren. Vorteil: Die Inhalte dieser Felder werden beim Absenden des Formulars mitgesendet. Wenn ich "disabled" verwenden würde, werden die Inhalte nicht mitgesendet. Da ich Felder im Formular abhängig von der Berechtigung editierbar mache, aber das Speichern im Backend nicht für jede Berechtigungsstufe individuell speichern möchte, meine Frage:

Gibts es noch irgendeine Möglichkeit, wie ich die Felder anzeigen aber nicht ändern lassen kann und beim Absenden des Formulars alle mitgesendet werden?

Bei Selectboxen und bei Radiobuttons könnte ich vielleicht auch ersatzweise ein Text-Feld mit readonly verwenden, aber bei Checkboxen eine Grafik einblenden?

Wie macht ihr das?`

LG Klaus

[dedlfix]

Tach!

Da ich Felder im Formular abhängig von der Berechtigung editierbar mache, aber das Speichern im Backend nicht für jede Berechtigungsstufe individuell speichern möchte, meine Frage:

Alles, was der Browser senden kann, kann manipuliert werden. Eine Prüfung auf Serverseite einzusparen ist fahrlässig.

dedlfix.

[TS]

Hello,

Da ich Felder im Formular abhängig von der Berechtigung editierbar mache, aber das Speichern im Backend nicht für jede Berechtigungsstufe individuell speichern möchte, meine Frage:

Alles, was der Browser senden kann, kann manipuliert werden. Eine Prüfung auf Serverseite einzusparen ist fahrlässig.

@Klaus1:

••• soll heißen, das ein readonly im Client serverseitig eine Entfernung des Elementes aus dem Updatestatement zur Folge haben muss, wenn Du z. B. SQL benutzt.

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Da ich Felder im Formular abhängig von der Berechtigung editierbar mache, aber das Speichern im Backend nicht für jede Berechtigungsstufe individuell speichern möchte, meine Frage:

Alles, was der Browser senden kann, kann manipuliert werden. Eine Prüfung auf Serverseite einzusparen ist fahrlässig.

@Klaus1:

••• soll heißen, das ein readonly im Client eine Entfernung des Elementes aus dem Updatestatement zur Folge haben muss, wenn Du z. B. SQL benutzt.

Eher soll es heißen, dass die Eingaben für diejenigen Elemente gar nicht beachtet werden, die aufgrund der Berechtigungslage nicht geändert werden dürfen. Dein Satz klingt mir so, als die Steuerung anhand der Client-Daten erfolgt. Das darf sie bei Berechtigungsfragen nicht.

Nicht immer kann/will man das Update-Statement direkt manipulieren (bei ORMs beispielsweise). Da ist die Vorgehensweise meist Lesen des Objekts aus dem DBMS, setzen der neuen Eigenschaften (in dem Fall lässt man die aus, die nicht geändert werden dürfen) und zurückgeben an das ORM zwecks Update-Speicherung.

dedlfix.

[TS]

Hello,

Nicht immer kann/will man das Update-Statement direkt manipulieren (bei ORMs beispielsweise). Da ist die Vorgehensweise meist Lesen des Objekts aus dem DBMS, setzen der neuen Eigenschaften (in dem Fall lässt man die aus, die nicht geändert werden dürfen) und zurückgeben an das ORM zwecks Update-Speicherung.

Genau das habe ich doch, verkürzt für normale Menschen, auch gesagt.

|READONLY => kein Update!|

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Nicht immer kann/will man das Update-Statement direkt manipulieren (bei ORMs beispielsweise). Da ist die Vorgehensweise meist Lesen des Objekts aus dem DBMS, setzen der neuen Eigenschaften (in dem Fall lässt man die aus, die nicht geändert werden dürfen) und zurückgeben an das ORM zwecks Update-Speicherung.

Genau das habe ich doch, verkürzt für normale Menschen, auch gesagt.

|READONLY => kein Update!|

Ich meinte aber "keine Berechtigung" -> kein Update. "Readonly" ist missverständlich, weil es sich sowohl auf die Berechtigung als auch auf die Markierung des Eingabefeldes beziehen kann.

Abgesehen davon, dass readonly nur auf text controls angewendet werden kann. Der Grund ist, dass es serverseitig nicht unterscheidbar ist, ob ein Element wegen readonly oder disabled oder nicht angehakt fehlt. Ich würde da nicht versuchen wollen, aus diesen drei Möglichkeiten diejenige zu erraten, die es sein soll. Den Aufwand, da eine eindeutige (und obendrein noch manipulierbare) Aussage hinzubekommen, kann man auch in eine serverseitige Berechtigungsprüfung stecken.

dedlfix.

[Klaus1]

Es geht nur um ausschließlich im internen Netz erreichbare Seiten. Alle Änderungen werden protokolliert. Damit wäre es Vorsatz, wenn jemand die Post-Daten manipuliert und hat sicherlich unweigerlich personelle Folgen.

[TS]

Hello,

Es geht nur um ausschließlich im internen Netz erreichbare Seiten. Alle Änderungen werden protokolliert. Damit wäre es Vorsatz, wenn jemand die Post-Daten manipuliert und hat sicherlich unweigerlich personelle Folgen.

Das ist der falsche Ansatz!

Wenn man eine Applikation durch gute Planung und Programmierung (meistens sogar ohne großen Aufwand) sicher und damit stabil (oder auch umgekehrt) machen kann, dann sollte man dies unabhängig vom Benutzerumfeld auch tun. Alles andere ist Sabotage!

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Wenn man eine Applikation durch gute Planung und Programmierung (meistens sogar ohne großen Aufwand) sicher und damit stabil (oder auch umgekehrt) machen kann, dann sollte man dies unabhängig vom Benutzerumfeld auch tun. Alles anderd ist Sabotage!

Ich würde es vermeidbare Fahrlässigkeit nennen. Zu Sabotage braucht es den Vorsatz, das System manipulierbar zu gestalten. Ich sehe hier nur, dass man sich Arbeit sparen möchte. Letztlich müssen wir hier im Forum das aber nicht rechtlich entscheiden.

dedlfix.

[TS]

Hello,

Wenn man eine Applikation durch gute Planung und Programmierung (meistens sogar ohne großen Aufwand) sicher und damit stabil (oder auch umgekehrt) machen kann, dann sollte man dies unabhängig vom Benutzerumfeld auch tun. Alles anderd ist Sabotage!

Ich würde es vermeidbare Fahrlässigkeit nennen. Zu Sabotage braucht es den Vorsatz, das System manipulierbar zu gestalten. Ich sehe hier nur, dass man sich Arbeit sparen möchte. Letztlich müssen wir hier im Forum das aber nicht rechtlich entscheiden.

Das Unterlassen von einfach möglichen Schutzmaßnamen, die vorhersehbare Fehler vermeiden können, ist mehr als grobe Fahrlässigkeit. Insbesondere, wenn man auf die Möglichkeit der notwendigen und einfach möglichen Maßnahmen aufmerksam gemacht wurde, ist die Unterlassung regelmäßig als Vorsatz zu werten und führt auch im Arbeitnehmerverhältnis zum Regress.

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Es geht nur um ausschließlich im internen Netz erreichbare Seiten. Alle Änderungen werden protokolliert. Damit wäre es Vorsatz, wenn jemand die Post-Daten manipuliert und hat sicherlich unweigerlich personelle Folgen.

Trotzdem. Man kann Manipulationsversuche ja anderweitig erkennen. Dazu muss man nicht erst das Kind in den Brunnen fallen lassen und dann hoffen, dass jemand erkennt, dass es da unerlaubte Änderungen gegeben hat. Am Ende kann man das vielleicht gar nicht mehr nachvollziehen, wie die Daten eigentlich sein sollen und es entsteht unnötiger Aufwand, sie zu korrigieren. Das ist ein eingespartes if-Statement nicht wert.

dedlfix.

[Tabellenkalk]

Hallo,

Es geht nur um ausschließlich im internen Netz erreichbare Seiten. Alle Änderungen werden protokolliert. Damit wäre es Vorsatz, wenn jemand die Post-Daten manipuliert und hat sicherlich unweigerlich personelle Folgen.

Nadann!
Schreib eine Info neben die Eingabe und weise auf den entsprechenden Paragraphen hin…

Gruß
Kalk

[TS]

Hello,

Es geht nur um ausschließlich im internen Netz erreichbare Seiten. Alle Änderungen werden protokolliert. Damit wäre es Vorsatz, wenn jemand die Post-Daten manipuliert und hat sicherlich unweigerlich personelle Folgen.

Nadann!
Schreib eine Info neben die Eingabe und weise auf den entsprechenden Paragraphen hin…

Gilt hier eigentlich auch betriebsintern eine Art DSGVO?

Wenn man seine Mitarbeiter überwacht, müssen die das doch vorher wissen!?.

Ich erinnere mich daran, dass ich mal einen MA hatte, der in seiner Arbeitszeit über unsere Telefonanlage Pornohotlines angerufen hat. Die verursachten Kosten gingen in die 1.000e. Die Loggingdaten der Telefonanlage (die zufällig eingeschaltet waren) durften wir nicht benutzen. Alleine deren Existenz hätte uns als Straftat ausgelegt werden können. Wir hätten die betroffenen Nummernkreise aber vorsorglich sperren dürfen.

So verkehren sich schnell Schuld und Sühne :-O

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Gilt hier eigentlich auch betriebsintern eine Art DSGVO?

Schon lange vorher gab es Reglungen, was an Daten gesammelt werden darf, und wie darauf hingewiesen werden musste. Das war zum Beispiel eine Vereinbarung zwischen Betriebsrat und Arbeitgeber.

Wenn man seine Mitarbeiter überwacht, müssen die das doch vorher wissen!?.

Eben. Dazu gibt es eine Menge Rechtssprechung, über die immer mal wieder in einschlägigen News-Portalen berichtet wurde.

So verkehren sich schnell Schuld und Sühne :-O

Wenn man verabsäumt, eine Vereinbarung zu treffen, welcherart Daten gesammelt werden dürfen, und außerdem zu regeln, wie Mitarbeiter die Betriebsmittel für private Angelegenheiten zu verwenden haben (oder auch nicht), darf man sich nicht wundern, wenn unrechtmäßig erhobene Indizien nicht als Beweismittel zugelassen werden. Generell ist der Tenor, wenn man die private Verwendung zulässt, darf man sie nicht überwachen, oder zumindest nur insoweit, wie es vereinbart wurde. Wenn Privatgespräche über eine bestimmte Amtskennzahl erlaubt sind, muss man die auch abrechnen und dafür Daten aufzeichnen können. Meist sieht die Vereinbarung dann vor, dass bestimmte Teile der Zielnummer gekürzt werden. Aus deiner Schilderung geht für mich hervor, dass die Firma dazu keine Reglungen getroffen hatte, und in dem Fall gibt es bestimmte Bereiche des Rechts, die stärker gewichtet werden als andere Interessen.

dedlfix.

[beatovich]

hallo

Damit wäre es Vorsatz, wenn jemand die Post-Daten manipuliert und hat sicherlich unweigerlich personelle Folgen.

personelle Folgen sollten ein Hinweis sein, dass das Argument Intranet irrelevant ist. Es braucht nicht mal Vorsatz, um Daten anders als erwartet zu erhalten. Wenn du auf der sicheren Seite programmieren willst, schreibst du deine Datenverwaltung unabhängig von User-Agents. Sonst kann am Ende nur ein Kopf rollen.

[pl]

Wie macht ihr das?

<fieldset disabled>..

MFG

[Just try it!]

Da ich Felder im Formular abhängig von der Berechtigung editierbar mache, aber das Speichern im Backend nicht für jede Berechtigungsstufe individuell speichern möchte,

Dreh es einfach rum. Speichere die Berechtigungen im Backend. Und wenn Du das Formular zusammenbaust frage eben das selbe Backend nach eben diesen Berechtigungen. Nehmen wir mal ein einfaches Backend mit einer ACL:

<?php
class accesControl {

    private $rights;

	function __construct() {
		$this -> rights = $this -> readRights();
	}

	function hasRight ( $rightname=false, $right='read' ) {
		$rights = $this -> rights[ $rightname ];
		if ( isset( $rights['user'][$_SESSION['username']][$right] ) && $rights['user'][$_SESSION['username']][$right] ) {
			return true;
		} else {
			foreach ($_SESSION['groups'] as $group ) {
				if ( isset( $rights['group'][$group][$right] ) && $rights['group'][$group][$right] ) {
					return true;
				}
			}
		}
		return false;
	}
	
	function readRights() {
	    /*
	    In der Realiät sollten die Daten freilich an anderer Stelle
	    ( Datenbank, Textdatei...) notiert werden!
	    */
	       
	    # Rechteobjekt, ACL-Type,   
	       
    $right['isDenied']['group']['deniedUsers']['read'] = true;
		$right['usermin']['user']['admin_1']['read']  = true;
		$right['usermin']['group']['admins']['read']  = true;
		$right['usermin']['user']['admin_1']['write'] = true;
		$right['usermin']['group']['admins']['write'] = true;		

		$right['logon']['group']['allusers']['read']  = true;
		$right['logon']['group']['logon']['read']     = true;

		$right['data']['group']['allusers']['read']   = true;
		$right['data']['group']['workers']['read']    = true;
		$right['data']['group']['workers']['write']   = true;
		
		return $right;
	}
}

/************************************************************
* Tests
************************************************************/

$acl = new accesControl();

/* 
$_SESSION['username'] und $_SESSION['groups'] sollten bei der Anmeldung 
besetzt werden
*/ 

session_start();

#/*
$_SESSION['username'] = 'admin_1';
$_SESSION['groups']   =  ['logon', 'usermin'];
checkRights( $acl );
#*/

#/*
$_SESSION['username'] = 'chef';
$_SESSION['groups']   =  ['allusers','usermin', 'workers' ];
checkRights( $acl );
#*/

#/*
$_SESSION['username'] = 'Leser';
$_SESSION['groups']   =  ['allusers'];
checkRights( $acl );
#*/

#/*
$_SESSION['username'] = 'Jobber';
$_SESSION['groups']   =  ['allusers', 'workers'];
checkRights( $acl );
#*/

#/*
$_SESSION['username'] = 'Denni';
$_SESSION['groups']   =  ['allusers', 'workers', 'deniedUsers' ];
checkRights( $acl );
#*/


function checkRights( $acl ) {
	if ( $acl -> hasRight( 'usermin' ) && false === $acl -> hasRight( 'isDenied') ) {
		echo  $_SESSION['username'] . " darf Benutzer ansehen" . PHP_EOL;
	}

	if ( $acl -> hasRight( 'usermin', 'write' ) && false === $acl -> hasRight( 'isDenied') ) {
		echo  $_SESSION['username'] . " darf Benutzer verwalten" . PHP_EOL;
	}

	if ( $acl -> hasRight( 'logon' ) && false === $acl -> hasRight( 'isDenied') ) {
		echo  $_SESSION['username'] . " darf sich anmelden" . PHP_EOL;
	}

	if ( $acl -> hasRight( 'data' ) && false === $acl -> hasRight( 'isDenied') ) {
		echo  $_SESSION['username'] . " darf Daten ansehen" . PHP_EOL;
	}

	if ( $acl -> hasRight( 'data', 'write' ) && false === $acl -> hasRight( 'isDenied') ) {
		echo  $_SESSION['username'] . " darf Daten schreiben" . PHP_EOL;
	}

	if ( $acl -> hasRight( 'isDenied') ) {
		echo  $_SESSION['username'] . " ist angemeldet aber blockiert" . PHP_EOL;
	}
}

Wo ist das Problem, beim Erzeugen des Formulars etwas wie

session_start();
require_once './lib/accesControl.class.php';
$acl = new accesControl();

if ( false === $acl -> hasRight( 'isDenied' ) ) {
?>
<h1>Ihr Account wurde gesperrt.</h1>
<p>Wenden Sie sich an den Chef.</p>
<?php
exit;
}

# …

if ( 
    $acl -> hasRight( 'data', 'write' ) 
 && $acl -> hasRight( 'data', 'read' )  
) {
		?>
<label for="p_serial">Seriennummer:</label>
<input type="text" value="1234" name="p_serial" id="p_serial">
    <?php
} elseif ( $acl -> hasRight( 'data', 'read' ) ) {
		?>
<label for="p_serial">Seriennummer:</label>
<input type="text" disabled value="1234" name="p_serial" id="p_serial">
    <?php
}

# …

zu notieren und vor dem Eintrag in die Datenbank genau das selbe zu machen?