MVC espone le chiavi primarie del database?

Ed è per questo che penso che questi tutorial semplificino le cose in una certa misura che confonde il nuovo arrivato.

Cerca di fare una piccola "tabula rasa" e pensa al processo da zero e disaccoppiando i concetti.

Prima di tutto, MVC è un livello di presentazione. Non sa (o non dovrebbe) nemmeno sapere cosa lo sta sostenendo. Potrebbe essere un database, un file xml, un file di testo, una raccolta in memoria, qualsiasi cosa. Dovrebbe essere estratto via.

Che cosa comprende MVC? Riceve una richiesta HTTP, la analizza tramite il motore di rotta, risolve il corrispondente metodo di controllo / azione e fa tutto ciò che scrivi nel metodo di azione. Fine della storia.

Chiede un id che, dietro le quinte, corrisponda a una chiave surrogata del database? MVC non lo sa. Per questo, è solo un parametro int di un metodo.

Dipende esclusivamente da te come dividi la tua logica e i tuoi livelli, come recuperi i dati e controlli la sicurezza.

Supponiamo che ti venga richiesto Prodotti / Dettagli / 1. Il tuo metodo di azione è sotto autenticazione (usando l'attributo authorize)? In tal caso, i tuoi prodotti sono visibili solo a determinati utenti?

Passerai a un metodo di business logic l'ID richiesto insieme al nome utente e quel metodo ti dirà "ecco il tuo prodotto" o "scusa, non puoi vederlo" in base alla logica interna. E diamine, se lo hai progettato bene anche il metodo della logica di business non saprà se dietro le quinte ha usato un database o qualsiasi altra cosa per recuperare il prodotto.

Spero che questa piccola spiegazione chiarisca un po 'le cose. MVC tratta solo di gestire le richieste HTTP e restituire una vista o alcuni dati JSON o qualunque cosa tu voglia restituire agli utenti. Tutto ciò che lo supporta dovrebbe essere astratto e implementato come meglio credi.

La visualizzazione della chiave è totalmente facoltativa, ma non è un problema di sicurezza, anche se lo si fa. È necessario verificare se l'utente ha accesso, sempre. Questo è il tuo lavoro, non quello del framework.

Ma non devi usare un ID numerico. Mi piace fare qualcosa come il tipo di contenuto e il titolo nell'URL:

/news/title-of-article
/reservations/description-of-hotel-and-reservation
/properties/address-of-property
etc.

Quindi uso queste informazioni per trovare il contenuto. Non per ragioni di sicurezza, il titolo è solo superficialmente più privato di un ID, ma per usabilità e / o SEO.

Mi piace anche consentire all'utente di eliminare lo slug (titolo, qualunque cosa tu voglia chiamarlo) nell'URL e ricevere esattamente ciò che si aspetta. Ancora una volta, solo l'usabilità, non la sicurezza:

/properties/address-of-property (single property)
/properties (list of properties)

Le app MVC hanno spesso una convenzione di default di controller / funzione / id. Questo è solo un valore predefinito. Non c'è motivo di usarlo se l'URL è importante per te. I tutorial di solito insegnano le impostazioni predefinite, ma dopo il tutorial è possibile (e dovrebbe!) Saperne di più. Quindi modifica le cose in base alle tue esigenze.

In ogni framework in cui ho lavorato, c'è stato un modo per mappare gli URL alle funzioni e passare i parametri (qualunque sia la parte dell'URL che si desidera). Hanno, senza eccezioni, stato chiamato "percorsi".

Usa percorsi ben studiati se vuoi un altro URL per gli utenti / motori di ricerca. Oppure usa il defualt se non hai bisogno di url migliori, ma vuoi semplicemente creare rapidamente l'app. Ad ogni modo, controlla se un utente ha il permesso di vedere qualcosa. Sempre.

Conoscere l'URL non deve essere uguale in grado di accedere ed è il tuo lavoro per applicarlo, indipendentemente dall'URL.

an invoice or transaction with confidential information on it if the key was sequential or guessable.

Anche se è probabile, non dovrebbe essere accessibile. Mostra qualcosa come un messaggio di errore "Accesso negato". I tasti sequenziali sono usati perché sono semplici e non contengono informazioni sul loro contenuto.

Sicurezza per oscurità (neener neener neener, non puoi indovinare l'ID!) non è sicurezza.

Questo è comune nelle esercitazioni e anche nelle semplici app in cui le chiavi di registrazione non sono sensibili. Ma MVC non ti obbliga a farlo in questo modo ... Se non vuoi usare ID sequenziali facilmente indovinabili, non devi farlo.

E per essere onesti, questo non ha nulla a che fare con MVC. Non riesco a contare quanti siti web ho visto dove la convenzione è qualcosa come /movies/details.aspx?id=5 o /movies/details.php?id=5

Questo è solo l'aspetto di routing standard di MVC. Un altro esempio potrebbe essere:

Movies/Details/{parentKey}/{thisKey}

Non dovresti aspettarti che MVC fornisca alcun livello di sicurezza. Questo è il tuo lavoro. Solo perché posso immaginare che esista una chiave di 5 , non significa che dovrei averne accesso. Qualsiasi ActionResult che ritieni possa rivelare dati sensibili dovrebbe avere un qualche tipo di sicurezza, sia nell'azione ActionResult sia utilizzando un AuthorizeAttribute su ActionResult (o anche sull'intera classe controller).