2010-06-04 2 views
0

J'ai un formulaire (composé de plus de 25 champs) et les valeurs de ces champs vont d'une petite valeur à une chaîne concaténée. C'est comme un outil de recherche. Maintenant, lorsque l'utilisateur remplit le formulaire et soumet l'information, il obtient de voir toutes les données pertinentes qui correspondent aux critères dans le formulaire. J'affiche 15 dossiers à la fois à l'utilisateur. J'ai implémenté la pagination pour permettre à l'utilisateur de voir les autres enregistrements.PHP, MySQL: Comment conserver et récupérer les données correctes lors de la pagination

le principal problème:

La partie, jusqu'à ce que les utilisateurs soumet les informations et récupère le 1er jeu de données est bonne. Le problème se pose lorsque l'utilisateur tente d'accéder à la deuxième page (ou à n'importe quelle page de son choix) via la pagination. L'utilisateur peut naviguer vers les autres pages, mais la requête nécessaire pour exécuter correctement les résultats de la base de données n'est pas déclenchée. Notez qu'initialement, il s'agissait d'une opération POST qui a été effectuée dans le formulaire et la pagination effectue une opération GET. Donc, je perds les valeurs de la forme que l'utilisateur a entré et je veux conserver ces valeurs et interroger la base de données avec ces valeurs. J'essaie d'éviter d'envoyer les valeurs du champ de formulaire via GET car je crains que les données puissent dépasser la valeur maximale autorisée dans l'URL (& car elle est moins sécurisée qu'une opération POST). D'autres opérations peuvent être effectuées sur la page de résultats, ce qui peut entraîner la perte des valeurs de formulaire si j'essaie d'utiliser une opération POST (comme une requête de mise à jour). Les sessions ne fonctionneraient pas vraiment car l'utilisateur peut choisir d'exécuter le même formulaire dans différents onglets avec des entrées différentes pour comparer les résultats, ce qui peut entraîner le remplacement des données de l'ancienne requête par les données de la nouvelle requête. Je n'ai pas pensé aux cookies car l'utilisateur a peut-être choisi de le bloquer. Presque toutes les options semblent être épuisées. Donc, que puis-je faire pour conserver les valeurs de formulaire, exécuter la requête appropriée et récupérer les valeurs pertinentes quel que soit le nombre de fois le même formulaire peut être traité par le même utilisateur dans différents onglets/fenêtres du navigateur, sans utiliser sessions (étant donné les restrictions sur le passage des données via GET et éventuellement les perdre dans les opérations POST) et être en mesure d'effectuer d'autres activités sur la page ainsi?

Merci d'avance.

Répondre

2

Tout d'abord, GET n'est pas "moins" sécurisé que POST. Les deux sont de ne pas faire confiance du tout (il est plus invitant à modifier une chaîne url, mais non plus durs) ...

Vous avez quelques options:

Un, serait de maintenir une approche globale " stocker "des résultats de recherche. Vous pouvez utiliser une table db avec id, data où data est un tableau sérialisé des variables. Ensuite, lorsque quelqu'un soumet une recherche, vérifiez si les données sont dans la table. Si oui, utilisez cet identifiant. Si ce n'est pas le cas, sérialisez les données et insérez-les (et obtenez l'identifiant). Puis rediriger vers une page comme: results.php?id=4. De cette façon, ils peuvent partager le lien, mais il reste raisonnablement sécurisé contre la falsification (ils ne peuvent pas modifier les paramètres de recherche). L'inconvénient ici, c'est que la table pourrait devenir énorme.

Un autre exemple serait de coder en base64 les données et de les transmettre en tant que paramètre get (base64_encode(serialize($data));). Je voudrais essayer de rester loin de cela si vous êtes préoccupé par la falsification ou la longueur de l'url.

Une autre solution serait d'intercepter le clic de lien suivant dans JS, et de l'utiliser pour renvoyer un POST à ​​votre serveur à partir de variables cachées.

EDIT: Suppression de la solution de session. Réalisé que cela ne fonctionnerait pas pour votre problème.

+0

Merci pour la réponse. Stocker dans la DB sonne bien. Je voudrais juste garder un onglet sur eux. Je vais réfléchir davantage sur la façon dont cela peut être fait avec la même approche. Merci. – Devner

+0

Comment un index sur une colonne de données (contenant le tableau sérialisé des variables) affectera-t-il nos résultats de recherche? L'index sera certainement plus rapide, mais compte tenu de la longueur des données, que suggérez-vous? – Devner

+0

Eh bien, créez deux index. Un PK sur 'id', et un index sur' data'. De cette façon, les deux opérations sont de simples recherches d'index ... Maintenant, puisque la longueur de l'index sur les données sera plus petite (Utiliser une colonne Text pour le champ 'data', donc l'index serait d'environ 255 caractères), ce n'est pas une véritable recherche d'index , mais il devrait être très rapide même avec des dizaines ou des centaines de milliers de recherches ... – ircmaxell

0

J'essaie d'éviter d'envoyer le formulaire valeurs de champ via GET parce que je crains que les données peuvent dépasser la valeur maximale admissible dans l'URL

Ensuite, vous allez devoir Faites aussi votre pagination avec un formulaire, afin qu'ils puissent également POST. Soit cela, soit vous devrez stocker des termes de requête sur le serveur quelque part, éventuellement dans une session - mais n'oubliez pas qu'un utilisateur peut avoir plusieurs onglets ouverts en même temps, vous devez donc pouvoir stocker plus de requête par utilisateur.

Mais il n'y a aucune raison pour laquelle vous ne pouvez pas stocker plusieurs requêtes en une seule session, par ex. $ _SESSION ["requêtes"] [1234]. Alors vos liens de pagination ressemblerait? Query = 1234 & page = 3

Considérons, cependant, qu'il peut être utile que les utilisateurs puissent partager des adresses URL de leurs résultats de recherche. par exemple, si Google utilisé POST exclusivement, je ne pourrais vous envoyer un lien vers http://google.com/search?q=somequery

(& comme il est moins sûr qu'une opération POST)

Pas vraiment.

+0

Merci pour la réponse. Les sessions sont moins utiles dans mon cas.Pourriez-vous me dire ce que vous avez mentionné au sujet du partage de l'URL? Je me suis un peu perdue sur ça. – Devner

+0

Supposons que votre utilisateur, Bob, souhaite partager la page des résultats qu'il regarde dans votre demande avec son collègue, Sally. Pour que cela fonctionne bien, l'URL dans la barre d'adresse doit contenir suffisamment d'informations pour reconstruire la requête entière. –

+0

Merci pour la clarification. – Devner

0

Une approche possible serait de stocker l'ensemble de la requête que vous avez utilisé pour la recherche dans votre base de données dans une table appelée search_queries. Cette table doit contenir essentiellement deux colonnes, un hachage et la requête utilisée pour cet élément de recherche. Quand un utilisateur soumet un formulaire de recherche, sa requête est évaluée et insérée dans cette table et il est redirigé vers une page avec son search_hash. Chaque fois qu'il navigue sur une page différente, son hash est extrait de la base de données et les résultats sont réévalués en conséquence - avec la limite appropriée, bien sûr.

Assurez-vous Cron cette table (pour que vous pourriez avoir besoin d'un horodatage pour chaque élément de recherche)

Une autre mise en œuvre viable de cette approche serait de stocker la requête dans une variable de session et de l'utiliser à vos besoins d'interrogation . Pour la pagination, vous devriez /search?page=1 et votre _SESSION['query'] serait par exemple "SELECT * FROM Topics WHERE title LIKE '%test%'". Vous ajouteriez essentiellement "LIMIT "+($page*$perpage)+", $perpage"

Cependant, cette dernière approche ne serait pas capable de détecter les multi-fenêtres que cet utilisateur a avec le site. Vous pouvez utiliser un tableau dans votre _SESSION ['requêtes'] et demander à l'utilisateur de soumettre un /search?id=0&page=1 où id représenterait quelle requête du tableau que vous interrogez dans cette fenêtre.

+0

Merci pour la réponse. Les sessions ne sont pas très utiles dans mon cas. J'ai pensé à utiliser le stockage dans DB comme ircmaxell suggéré et je vois que vous avez suggéré une approche similaire d'une manière un peu différente. Merci pour la même chose. – Devner

Questions connexes