Sto costruendo una semplice app CRUD (non usando il modulo CRUD).Come impedire che i campi nascosti con ID vengano violati
Il mio modello è una classe semplice con un attributo. l'id è implicitamente ereditato dal modello.
@Entity
public class Account extends Model {
@Required
public String domain;
}
La vista è la seguente. Si prega di notare il campo nascosto con id.
<form class="form-horizontal" action="@{Application.save}" method="POST">
<fieldset>
<legend>Settings</legend>
<input type="hidden" name="account.id" value="${account?.id}">
#{field 'account.domain'}
<div class="control-group #{if field.error != null} error #{/if}">
<label class="control-label" for="${field.id}">&{field.name}</label>
<div class="controls">
<input type="text" class="input-xlarge" id="${field.id}" value="${field.value}" name="${field.name}">
<span class="help-inline">${field.error}</span>
</div>
</div>
#{/field}
<div class="form-actions">
<input class="btn btn-primary" type="submit" value="Save">
</div>
</fieldset>
sono stato in grado di costruire uno scenario in cui salvare, aggiornamento funziona.
Il modo in cui viene eseguito l'aggiornamento è che leggo l'ID dal campo nascosto e aggiorno il record. Se l'ID non è disponibile, viene creato un nuovo record.
Quindi la domanda è: È possibile che l'ID venga violato, modificato in modo da cambiare 1 a 2 e supponendo che un record con 2 esista, viene sovrascritto. (Suppongo che non dovrebbe essere difficile con firebug o altri plugin).
Come si impedisce questo? Un'opzione che ho pensato è quella di leggere il record con l'Id dato, se l'utente è autorizzato a modificarlo, autorizzo l'aggiornamento, altrimenti no. Questo non è ancora infallibile perché, mentre l'utente potrebbe essere autorizzato, il record "errato" potrebbe essere modificato.
Immagino che questo sia un problema noto e, si spera, con una soluzione nota.
Grazie per aver trovato il tempo di rispondere alla mia domanda.
Questo sembra essere esattamente ciò di cui avevo bisogno. Crypto.sign calcola la firma HMAC.SHA1. Lo proverò stasera. Quello con cui stavo rimuginando era avere un segreto specifico dell'utente, ma quello è un dettaglio di implementazione. Hai fornito chiarezza alla foschia nella mia mente. Grazie :) – Nasir
funziona come un fascino. Più semplice del mantenimento dello stato sul server. Ho intenzione di utilizzare le chiavi specifiche dell'utente che genererò al momento dell'iscrizione invece del segreto dell'applicazione che viene utilizzato di default. [Metodo di firma con 2 parametri] (http://www.playframework.org/documentation/api/1.2/play/libs/Crypto.html#sign%28java.lang.String,%20byte []% 29) – Nasir
I ' Non sono sicuro del motivo per cui ti daresti fastidio. Il framework Play è completamente senza stato. Se riesce a capire che solo l'ID account 1 può essere modificato sul GET, perché non lo può capire di nuovo sul POST? La sessione identifica già l'utente. Non c'è motivo di crittografare qualcos'altro. –