Architettando un'applicazione con un'interfaccia utente javascript a singola pagina

3

Ho un'applicazione a pagina singola in cui tutto nell'IU è guidato da javascript, quindi qualsiasi operazione che richiede dati o aggiornamento di dati viene eseguita tramite richieste Ajax. Il modo in cui le cose sono configurate in questo momento è che il mio Ajax chiamato è fatto su un file ajax.php che si occupa di instradarle al metodo di servizio appropriato. Funziona bene ma c'è un problema. Ogni volta che ho operazioni che richiedono un ID utente, non voglio passarle come parte di una richiesta Ajax in modo da evitare manomissioni. Dal momento che ho una sessione in esecuzione sul lato server, dispongo di un servizio di sicurezza da cui posso recuperare l'ID utente dell'utente attualmente connesso. La sicurezza lo fa utilizzando un oggetto Sessione che astrae l'accesso alla sessione (nel mio caso , $ _SESSION in PHP) implementando un'interfaccia. Il mio servizio di sicurezza viene iniettato in altri servizi, se necessario, quindi ad esempio, se ho un metodo PostService- > findUserPosts (), quel metodo usa il metodo getUserId () dell'oggetto SecurityService inserito per capire l'ID utente invece di avere è passato come argomento.

Il problema è che sospetto (e altri sembrano essere d'accordo) che non passare l'ID utente al servizio è una cattiva progettazione. Ma come faccio a farlo senza mandare l'ID utente via ajax? Posso pensare ad alcune opzioni, nessuna delle quali mi piace o conosco un buon modo per implementare:

1) Aggiungere un livello controller sul lato server, nel qual caso posso chiamare SecurityService- > getUserId () nel controller e inoltrare una chiamata separata a PostService- > findUserPosts ($ userId); il problema con questo approccio è che mi richiede di aggiungere un gruppo di controller che sono per la maggior parte abbastanza ridondanti. Così com'è, ho già un metodo PostService- > findPosts () che fondamentalmente chiama solo PostGateway- > findPosts (). Posso vivere con quella ridondanza perché ci saranno molti posti in cui il servizio dovrà fare di più. Ma aggiungere un terzo livello con un controller con un metodo findPosts (), sembra troppo doloroso.

2) Passa l'ID utente nella richiesta Ajax e crea una sorta di meccanismo di manomissione per assicurarti che la richiesta di ajax non possa essere modificata. Potrei farlo tagliando la stringa URL della mia richiesta e aggiungendola come parametro, e poi sul server confrontando l'hash. Questa è più offuscamento di qualsiasi altra cosa, dato che l'hash dovrebbe essere generato lato client, il che significa che qualcuno che guarda attraverso il codice potrebbe capire come viene generato l'hash.

3) Mantenere le cose come sono, tenendo presente che il mio ID utente è almeno non codificato e possono essere utilizzate varie implementazioni dell'oggetto Session, in questo modo l'ID utente può essere recuperato in diversi modi, senza vincolarmi all'oggetto $ _SESSION PHP.

4) Utilizzare un metodo ibrido di # 1 e la configurazione corrente in cui, se ho bisogno di accedere alle informazioni sulla sessione, utilizzo un controller, altrimenti chiamo direttamente il servizio. Questo potrebbe funzionare, anche se non sembra un approccio pulito e unificato.

Ho cercato di capirlo con due domande separate che trattano problemi separati più piccoli, ma penso che la mancanza di contesto rendesse difficile rispondere, quindi ho pensato di formulare una domanda con l'intero problema. I suggerimenti sono ben accetti I suggerimenti sono ben accetti O dovrei dire, tanto bisogno!

UPDATE: forse un compromesso valido sarebbe avere un metodo PostService- > findByUser ($ userId) e poi avere un metodo UserService- > findPosts () che ottiene l'ID utente da SecurityService PostService è lo stesso che fa ora?

    
posta Rocket04 13.02.2013 - 18:39
fonte

2 risposte

2

Suggerisco cosa fai, piuttosto che avere gli ID utente visibili sul lato client, implementa un token.

Funzionerebbe così:

  1. L'utente accede, ne prendi nota sul back-end e genera un token che ha una scadenza
  2. Si restituisce il token al client (browser)
  3. Per ogni richiesta successiva, si passa il token al server come garanzia di sicurezza. Per ogni chiamata andata a buon fine si aumenta la scadenza del token di + n minuti / ore o qualsiasi cosa sia adatta a te. Prima di eseguire la richiesta di servizio, assicurati che il token sia valido e non sia scaduto.
  4. Quando l'utente si disconnette o il token scade, eventuali chiamate di assistenza successive non verranno eseguite.

Il mio suggerimento sarebbe di richiedere sia un ID utente che un token. L'ID utente sarà inutile senza il token e richiedere l'ID darà un po 'più di sicurezza extra contro lo spoofing dei token. Usa la funzione PHP uniqid per generare un token univoco come punto di partenza.

    
risposta data 10.03.2013 - 16:13
fonte
0

Se l'utente ha già effettuato l'accesso e ha una sessione, il browser sta già utilizzando un cookie di sessione che è un token. Non riesco a capire perché vorresti implementare la tua soluzione token quando la gestione delle sessioni è standard e affidabile. Il tuo file php è sul tuo server, quindi puoi usare la tua password per accedere ai servizi che l'utente non vedrà mai sul browser. È già possibile avere il proprio ID utente nella sessione perché hanno già effettuato l'accesso. Passare l'id utente ai servizi per la conservazione dei registri ma "accedere" ai servizi utilizzando la propria password dell'applicazione Web per quel servizio che è memorizzato sul server php. Mi piace la tua soluzione perché non stai provando ad accedere a più servizi direttamente dal browser, ma stai usando il tuo server php come una sorta di proxy. Sembra anche che tu stia usando php che il tuo layout di consegna sia combinato con i dati ma usando innerhtml per visualizzarlo nel DOM. Potresti voler esaminare un framework di iniezione HTML in modo da non dover reinventare la ruota durante questa operazione.

    
risposta data 09.01.2016 - 04:54
fonte

Leggi altre domande sui tag