Du JSON dans les variables GET, qu'en pensez vous ?

Bonjour,


Ayant à ma charge la mise en place d'un web service (API), j'utilise à l'instars de Amazon et d'autres géants du web, une authentification et contrôle d'intégrité basé sur HMAC avec SHA1, cependant au vu de la complexité à "canoniser" les données à signer (url trié par ordre alphabétique pour OAuth par exemple, etc...), sans compter les possibles erreurs liés à l'ajout de paramétres par composant ou librairie tiers...

J'ai réfléchis à une solution (qui existe peut-être déjà mais rien trouvé a ce sujet) qui consisterai à serializer tous les paramétres GET, dans un objet JSON (à l'instars du JSON/RPC en plus soft), puis l'objet JSON serais stringifié dans une variable GET prédéfinie (admettons 'requete'), ainsi le calcul de la signature avec HMAC_SHA1 et la clée privée et accessoirement le nonce/timestamp, serais plus simple, car plus besoin de 'canonisation' lourde et contraignante de la part du serveur et du client.

Certes le temps alloué à la canonisation des données et substituer en partie par la création et la stringification de l'objet JSON, mais sa ma l'air quand même moin source de vrai-faux positif lors du controle de la signature par le serveur.

Pensez-vous que ce que je propose est un pure sacrillége de 'non optimisation' ou au contraire peut s'avérer utile ?

Je ne vois pas l'intérêt. Tu as l'air de chercher à résoudre un problème, mais on se demande bien lequel.
Signer des requêtes est simple et rapide.

Il y a en pourtant un, OAuth 1.0a, impose le respect de contraintes appliqués sur le jeux de variables à transmettre pour la signature en amont et aval pour la comparaison des deux HMAC, augmentant la probabilité de vrai faux lors du controle de la signature, les exemples sont à foisson sur la toile :

http://developer.linkedin.com/docume...authentication
http://oauth.net/core/1.0/
http://c.ittoolbox.com/groups/techni...matter-3774417


Ainsi la serialisation avec JSON va nous éviter se genre de probléme, de plus la transmission sous format JSON des variables permet de représenter des structures de données plus complexe et de façon plus simple que par le recourt à une myriade de variables GET.

Cependant je l'accorde le seul revers de médaille est la légére augmentation de la taille des données transmises (qui n'est pas bien importante par rapport à des supports 'verbeux' tel que le XML, etc...).

Oui je connais ces contraintes, mais tu parles d'un "problème à éviter." Lequel ? Si tu fais du OAuth, c'est pas le JSON qui va te dispenser de respecter les contraintes. Et puis de là à appeler ces contraintes un "problème"... Dans les URL aussi il y a des contraintes à respecter, ça dérange personne.

À la rigueur "l'exemple" des données à trier, qui donc n'est pas un exemple mais la seule chose où ton JSON machin peut intervenir, ça évite de te retrouver avec un ensemble variable de noms à ordonner, et du coup t'as juste à regarder au moment où tu programmes, dans quel ordre ils vont, au lieu d'avoir un algo de tri.
... C'est... pas quelque chose qui viendrait à l'esprit normalement. Ça a jamais été difficile de faire ça, alors que passer par une couche de sérialisation, merci. Si les gens se plantent, c'est parce qu'ils ont pas compris que si, il faut bel et bien trier et que s'ils ont pas quelqu'un qui le fait à leur place, personne le fera. À partir du moment où tu sais qu'il faut trier, il n'y a pas de problème.



Pour les données complexes, ben l'idée justement c'est d'arrêter les GET et se mettre au POST ou au PUT. Après c'est pas toujours possible, je suis d'accord. Un POST ou un PUT servent à envoyer des entités, or ce que tu cherches à transmettre pourrait n'être qu'un paramètre qui, aussi complexe soit-il, n'a pas lieu d'être l'entité d'une requête.

Le prix, en fait, c'est pas juste le coût en place de l'encodage. C'est aussi que ton GET tu l'as fait à une URL, et que cette URL est incompréhensible. On peut la comprendre qu'après deux couches : une métier parce que c'est ton truc à toi, et une standard pour indenter le JSON.
C'est pas bien élégant, pas bien prévu pour, mais bon, en effet, ça vaut pas non plus la peine de se casser la tête des heures si on a rien trouvé d'autre.