Perché impiegare un motore di ricerca basato su POST sul proprio sito web?

Question

Perché impiegare un motore di ricerca basato su POST sul proprio sito web?

#1 da (4 voti)
#2 da (-3 voti)

0

Una ricerca Google su questo argomento restituisce solo i risultati che spiegano come hackerare la ricerca nel sito di Google Analytics per la misurazione dei motori di ricerca basata su POST. Quindi, pensavo di rivolgermi a voi uomini e donne per aiuto.

So che le principali differenze tra GET e POST riguardano la sicurezza e il caching (le richieste POST sono sicure e non vengono memorizzate nella cache). Quindi, per alcune applicazioni ha perfettamente senso usare POST piuttosto che GET.

Tuttavia, sto lavorando con un motore di ricerca interno del sito che riceve e restituisce richieste SERP stile POST. Perché dovrebbe essere progettato per farlo? Quali sono i vantaggi? Non riesco a immaginare che sia importante mantenere le query di ricerca sicure. Forse ha qualcosa a che fare con il non mettere in cache quelle query?

Tutto quello che vedo è una complicazione per Web Analytics, quindi sono davvero alla ricerca di illuminazione.

Grazie in anticipo a chiunque possa aiutarmi a capire questo.

websites search-engine analytics

posta Ryan Keeler 06.07.2016 - 14:18

fonte

2 risposte

Leggi altre domande sui tag websites search-engine analytics

URL endpoint che concatena Iniezione di fabbrica nell'oggetto creato in fabbrica

score 4 · Answer 1

Quindi, quando una richiesta GET viene inviata su HTTPS, i suoi parametri di ricerca sono al sicuro durante il transito. Tuttavia, può più facilmente perdere dati sugli endpoint (cronologia del browser, URL di riferimento e log del server in particolare) rispetto a POST. Vedi questa risposta e questo vecchio post del blog .

A parte la perdita dei referrer, di solito non sono troppo preoccupato per l'utilizzo di GETs. OTTENI gli URL sono piacevoli proprio perché puoi aggiungere ai segnalibri e condividere le query che esegui normalmente. Spesso, se decido tra POST e GET per le query, si riduce a questi fattori:

I parametri di ricerca possono rientrare in una stringa di query URL?

Alcuni browser tronceranno gli URL oltre un determinate dimensioni .

Se hai un oggetto complesso che rappresenta la tua richiesta, allora può essere difficile da convertire in / da una stringa di query URL automaticamente.

Il mio oggetto di richiesta è utile come parte dell'URL?

Anche se può convertire / adattare un oggetto a una rappresentazione di stringa di query, ciò non significa che sarà utile farlo. Se hai troppe proprietà, è ancora noioso costruire stringhe di query nel browser.

Al contrario, usando il POST puoi includere il tuo oggetto di richiesta complesso o grande come JSON o qualsiasi altro formato ti piaccia. Se vuoi registrarlo, puoi ancora tramite la tua applicazione.

Uso spesso GET per ricerche di testo completo:

GET /customer?skip=0&take=50&search=my+search+text

Ma per scenari più complessi, potrei usare il POST sulla base dei fattori guida sopra.

Se guardi la maggior parte dei motori di ricerca, usano GET con i parametri di query. È la soluzione migliore per quello che fanno. Per i servizi di analisi POST-based ha senso, perché offre un controllo molto più preciso sulle tue richieste tramite oggetti di richiesta più complessi.

score -3 · Answer 2

Non è che le ricerche siano dannose; qualsiasi input in qualsiasi sistema, "POTREBBE" essere malizioso. Dobbiamo pensare in questo modo. E, sì, GET è meno sicuro del POST. GET può tralasciare dei passaggi che aiutano a proteggere le risorse.

Per prima cosa, prova a pensare alla ricerca come a un input sulla superficie di attacco. In questo caso la porta 80 o 443, ad es. stanno ascoltando le richieste del metodo HTTP. In questo caso, la ricerca è un POST. Il POST potrebbe richiedere l'autenticazione. Potrebbe richiedere l'autorizzazione di qualche tipo. Tuttavia, per il POST, vengono specificati i dati di input previsti per la ricerca, ma è richiesto il formato POST. Questo protegge la ricerca più di GET perché il POST è generalmente formattato perché è messo insieme dalla pagina web con il pulsante di invio.

Gli utenti malintenzionati possono ancora disegnare un'operazione HTTP POST di origine malevola, ma il server non invierà nulla a meno che l'applicazione non abbia implementato un'operazione di post del particolare formato. Inoltre, gli exploit di cross-site scripting sono molto più difficili con l'uso del POST.

Ancora una volta, non è una funzione di "ricerca", è una funzione di "input" del server vulnerabile con lo spazio dei nomi "cerca".