Sur la predictibilite des id, yavait un bon article des mecs de youtube sur le sujet si je dis pas de conneries.
Je sais pas trop comment le retrouver mais ya beaucoup de ressources concernant ce sujet sur stackoverflow. Cet article est exactement la conversation que nous avons et les reponses (surtout celles de emboss a mon gout) sont tres pertinentes. http://stackoverflow.com/questions/10785814/randomize-db-record-ids Il en ressort que les problemes d'acces ne sont pas du ressort de la prediction des id (mais du systeme de droits, c'est du bon sens). Pour ce qui est de la volumetrie sans aucune possibilite de deduction, emboss donne une reponse pas mal a base de pre-calcul de seeds completement random. Tu peux aussi renvoyer la meme erreur que l'id n'existe pas en base ou qu'il ne soit pas accessible. Ca n'empeche pas le monitoring au cours du temps (rendu moins pertinent plus le nombre de clients est eleve). Une autre solution qui n'a pas ete evoquee est de runner une instance d'appli par client. Chaque client a son propre set d'id et ne connait pas les autres clients ni lurl de leur app. Ca s'industrialise mais demande le developpement d'une app supplementaire pour gerer le deploiement des apps des nouveaux clients. A moins que tu aies une relation de proximite avec tes clients (deploiement sur site, eventuellement sur leur propres serveurs, eventuellement coupe du reste genre intranet). La solution que tu cherches n'est peut etre pas une solution qui se resout par un algo ou une gem mais peut etre, dans ton cas (que je ne connais pas) par une adaptation de ta politique commerciale. Jespere avoir pu t'ouvrir des pistes si les reponses precedentes ne repondaient pas a ton probleme. Peace :) On Jul 31, 2014 11:42 PM, "Sylvain Abélard" <[email protected]> wrote: > Hello, > comme tu le notes, on peut estimer les produits (bof) ou volumes de ventes > etc. > > Soit en testant et en voyant ce qui marche ou pas, soit en ayant une > volumétrie permettant de faire de la stat : > http://en.wikipedia.org/wiki/German_tank_problem > > Si elles sont inutiles, tu n'as pas besoin de t'en inquiéter. > Mais ce sont des choses que tu n'as pas envie de donner : > > 1. aux investisseurs, racheteurs, futures recrues, si tu es en dessous de > la perf annoncée. > Ces chiffres se falsifient de toutes façons, et les conséquences d'un > mensonge sont pas top. > "Honesty is the best policy", je trouve ça pervers. C'est dur, grave > et inutile de mentir. > Ça marche aussi pour ton client, les impôts, la presse, ta femme... > etc. > > 2. aux concurrents, si tu vends un produit sans trop de différence de > valeur ajoutée > - un objet/service similaire sur lequel ils peuvent vendre moins cher > - un objet/service sur lequel votre seule différence est la com / > l'image > - un objet/service sur lequel votre seule valeur ajoutée est la mise > en relation (et rien d'autre) > > Je ne baserai pas ma vie et celle de ma famille sur un tel business mais > ils sont nombreux. > Ce sont des clients qui justement ont besoin de ton code pour se > différencier : dans la vente ou les process, ou dans la connaissance du > marché / de leur boîte. > Ce sont des raisons légitimes : ton client n'a pas envie d'offrir à ses > concurrents la possibilité de scruter sa stratégie pour qu'ils en fassent > un contrepoint. > > > À titre personnel je recommande les classiques Brakeman etc. > Je seconde la solution de Thibaut qui est de faire un loader / param > sanitizer custom pour chaque cas, après c'est pas mal de boulot à coder et > je n'ai pas de gem magique pour ça (ça me semblerait risqué, long à > configurer, ou pas top sur la perf). > Heureusement cette partie-là c'est pas moi qui la code, elle se génère > toute seule ;) > > À bientôt, > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > --- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > "Railsfrance". > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse > [email protected]. > Pour obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
