ypicot

Membres
  • Content count

    929
  • Joined

  • Last visited

About ypicot

  • Rank

  • Birthday 10/01/1963

Profile Information

  • Genre
    Homme
  • Lieu
    banlieue sud de Paris

Previous Fields

  • FM
    FMP8 - 9
  • OS
    WinXP-Linux
  • Certification
  • FBA
    Membre

Contact Methods

  • Website URL
    http://www.ypicot.fr

Recent Profile Visitors

14,956 profile views
  1. Je ne suis pas certain de comprendre ton besoin, donc il est possible que je réponde à coté. L'idée est de ne pas stocker login (et encore moins le pw) dans l'url. L'uuid que tu décris (qui est bien souvent le résultat d'un hachage quelconque) est stocké en base, dans la même table que le login et le pw. Quand ton script reçoit un un uuid, il le recherche simplement dans la base, lit le login de l'utilisateur, et ouvre une session avec. Deux remarques cependant : - ne pas stocker le pw en clair est très-franchement-beaucoup conseillé (en cas de compromission de la base) - en principe, ce genre de système est à usage unique, et limité dans le temps (lien valable 24h par exemple). A utiliser, par exemple, en cas de perte du pw. N'oublie pas que la confidentialité d'un email est à peu près celle d'une carte postale : beaucoup de gens peuvent y accéder sans faire trop d'effort, sans compter les différents piratages de boite. Quand tu développes pour le web, il faut être paranoïaque. Yvan
  2. Cette directive interdit tout logiciel fait maison sans liaison externe, quel que soit l'environnement de développement. En effet, qui dit "c'est fait maison" dit "je suis admin", donc "je peux tripatouiller les données", et le texte cherche justement l'impossibilité de tripatouillage (tous ceux qui ont travaillé dans l'hôtellerie / restauration -mais pas seulement- comprendront parfaitement le sens de ce texte). D'après ce que j'ai compris (à vérifier, donc), le seul moyen de s'en sortir est de prévoir une liaison avec l'extérieur, liaison à travers laquelle le logiciel enverra à "un tiers de confiance" une copie de chaque transaction au moment ou celle-ci est réalisée. En d'autres termes, quand je créé une pièce comptable (ticket de caisse ou facture), j'envoie immédiatement une copie de ladite pièce à une société qui ne fait que la recevoir et l'archiver, mais qui en cas de contrôle peut garantir qu'elle ne sera jamais modifiée ou effacée. Et qui, accessoirement, n'oubliera pas de me facturer ce service. Yvan
  3. Je note donc qu'il faut nettoyer quand on a beaucoup de sexe... Yvan
  4. Pourrait-on envisager une mise à jour du certificat ? Je sais qu'il suffit de rajouter une exception de sécurité (ce que j'ai fait), mais disons que cela ne fait pas très propre... C'est juste histoire de signaler un petit problème, au cas où les admins ne soient pas au courant. Ce fil pourra d'ailleurs être supprimé après résolution dudit problème. Yvan
  5. Triste nouvelle. Au revoir, Gilles
  6. Bonjour Bien que pas plus enchanté que toi par la direction prise par Filemaker, je ne peux pas laisser passer une comparaison aussi biaisée. En effet, tu ne peux pas comparer un bien immatériel (une licence) et un bien matériel (une voiture, ou tout autre objet manufacturé), ne serait-ce que pour le coût marginal, c'est à dire en gros le coût de fabrication (j'ai dit "en gros", hein... les puristes sont priés de ne pas râler). De plus, la vente "à perte" auprès des associations est rarement coûteuse. Il y a bien sûr l'effet réseau (je connais Filemaker que j'utilise dans mon association, j'en parle autour de moi, donc je fais de la pub), le fait que le coût marginal est quasi-nul, et de plus je soupçonne très fort Filemaker.inc de faire comme son copain Microsoft. En effet, MS propose des tarifs "association à but non lucratif", très intéressants, allant jusqu'à la gratuité sur Office365 ou Sharepoint (donc, un service qui coûte des ressources : serveur, bande passante, ...). Simplement, MS va considérer qu'une partie (ou totalité, j'avoue ne pas avoir bien cherché) de ce "don" va en déduction fiscale, et est donc financièrement intéressante. Je précise que ceci n'est pas caché par MS, mais annoncé publiquement. Savez-vous si m'sieur FM fait officiellement comme m'sieur MS ? Yvan
  7. Bonjour En arrivant avec un firefox sur la page de login, j'ai eu droit à un magnifique ; Je ne sais pas si cette erreur apparait quand on enregistre son login/pw dans le navigateur (perso, je ne les enregistre jamais). Yvan
  8. Est-ce que ton modèle contient bien les 36 rubriques ? Yvan
  9. Plusieurs questions en une seule. Cherches-tu - une comparaison des fonctionnalité / capacités ? Sujet trop vaste, et réponse dépendant totalement du contexte - une comparaison de la facilité d'accès / d'apprentissage ? Tout dépend des connaissances. Access semblera plus "naturel" à qqu'un qui a des connaissances en base de données par ailleurs (structure plus habituelle), alors que FM est plus accessible à des personnes "vierges". - une comparaison entre les macros d'Access et les scripts FM : avantage sans conteste à FM, qui est beaucoup plus puissant en étant à peine plus complexe. Mais pour rappel, les macros ne sont utilisées que dans des contextes bien précis (typiquement : l'intégration dans Sharepoint d'une solution Access) - une comparaison entre le VBA d'Access et les scripts FM (dans Access, et contrairement à Excel, "macro" et "VBA" désignent deux choses différentes) : le VBA est beaucoup plus puissant, mais également beaucoup plus délicat à maitriser. On revient à la 1ère réponse : tout dépend du contexte. Après, tout un tas de considération peuvent intervenir à coté des aspects purement techniques : le niveau de sécurité requis, l'acceptation par la DSI de tel ou tel logiciel, le coût des licences dans le cas d'une utilisation multiposte, culture (et connaissances) de l'entourage sur tel ou tel logiciel, ... Si ton application est relativement simple (et cela semble être le cas), je ne peux que suggérer de rester sur FM (conseil de la part de qqu'un qui maitrise parfaitement Access). Yvan
  10. - ESS => regarde la doc (mais pas d'ESS sur un mutualisé. Il faut nécessairement ton propre serveur, pour pouvoir installer ODBC)- par fichier => export d'un fichier .csv par FM, transfert (manuel ou automatique, par ftp ou en écrivant une routine d'import en PHP), puis intégration dudit fichier dans MySQL (là encore, manuel ou automatisé) Tu t'organises comme tu veux : une base de données globale, une base par client, une base par campagne... Un CRM coté PHP est totalement superflu. A toi de voir ce que tu désires proposer coté FM. ESS, import plus ou moins automatique de fichier .csv... plusieurs solutions existent, il me semble qu'elles ont été évoquées dans ce forum. Dans ce cas il n'y pas de base de données MySQL, mais c'est FileMaker qui fait base de données ?Oui, tout à fait Cela a été évoqué par Olivier : tu risques d'avoir qques problèmes d'accès si 10 clients répondent en même temps (ou alors, tu blindes et tu achètes 20 connexions WebDirect, en surveillant les pics de connexion pour voir comment cela se passe quand tu en envoies 200, 500, ... emails d'un coup.Reste à savoir comment cela peut s'organiser coté WebDirect : c'est une techno que je ne connais pas du tout, notamment quand on envoie une URL telle que celles évoquées plus haut. Je te suggère très fortement de passer un peu de temps sur des tutos sur le principe des sites web (et notamment la notion de "requete/réponse", qui perturbe ceux qui viennent de FM, d'Access ou autre client lourd) et sur PHP. Ceux de OpenClassRooms, par exemple, font référence. Yvan
  11. Je vais essayer de détailler la solution proposée par Olivier ** en début de campagne, FM envoie à PHP (différentes approches possibles : ESS, envoi d'un .csv, ...) une table contenant des infos telles que id, nom, prénom, age du grand-frère, ... et deux chaines uniques indiquant si l'utilisateur a voté OUI ou NON. ** dans le mail, 2 liens : - le premier pointant vers www.monsite.fr/vote.php?reponse=ufodq789qflSDDS78 qui dit en gros "le client UNTEL a voté oui" - le deuxième pointant vers www.monsite.fr/vote.php?reponse=er789xdufhjk3juTYF qui dit "le client UNTEL a voté non" le "ufodq789qflSDDS78" est une chaine *unique* et plus ou moins aléatoire (réellement aléatoire ou encodage genre SHA1 ou autre) qui a été générée par FM. ** quand l'utilisateur clique sur le lien, il envoie une URL à PHP, qui va - recevoir l'info et la sécuriser (enlever les éventuels caractères zarbis et autres vecteurs d'attaque) - en fonction de la chaine, retrouver l'utilisateur et sa réponse - stocker la réponse dans une BDD genre MySQL - afficher un msg à l'utilisateur "merci monsieur UNTEL d'avoir voté OUI" ** A intervalles réguliers, FM va lire la base de données (là encore, différentes approches possibles) et récupérer la réponse de l'utilisateur. Il faut bien sûr traiter le cas de votes multiples (le même utilisateur qui clique plusieurs fois sur le même bouton, ou sur un bouton différent), la date de péremption du lien et autres considérations annexes. A partir de ce scénario de base, plusieurs variantes sont possibles : - utiliser l'API PHP de FM pour ne pas avoir à passer par MySQL - le mail n'utilise qu'un seul lien identifiant le client, et tu as un petit formulaire PHP qui propose le choix "oui ou non" - ... Yvan
  12. Tu reviens sur le coté "moins professionnel" de la solution par mail : tu n'as aucun moyen d'éviter la demande d'envoi de mail. Ce petit détail risque fort de déplaire aux clients de tes clients : a leur place, je me poserai des questions, et je pense que je n'enverrai pas de réponse du tout. Du coup, tes clients ne vont pas être très contents. Même si je rejoints totalement Ugo et Olivier sur la solution PHP (mais peut-être parce que je maitrise cette techno), j'aime bien l'approche de Arch-info, qui envisage le problème sous des angles différents. Une autre approche : puisque tu aimes te triturer les méninges, pourquoi ne pas en profiter pour apprendre le PHP, éventuellement en te faisant accompagner ? Surtout que ton problème est très simple par rapport à un site "normal". Yvan
  13. Presque : il y a certaines limites, même sur un windows récent (seven ou après) : si le disque est le disque de démarrage et que le bios n'est pas en UEFI, tu seras limité à 2To (moins l'OS et qques fichiers) De même, si tu as un disque formaté en FAT32, tu seras limité (à 2To si ma mémoire est bonne). Donc, FM ouvre un petit parapluie, en disant "8To, ou moins si vous vous êtes mal démerdé" Yvan
  14. Effectivement, c'est très bizarre... Tu peux ajouter un "ORDER BY ref_produit" à la fin de ton instruction SQL pour avoir un "regroupement visuel" (ce qui permet de vérifier qu'on n'a pas oublié qque chose dans un coin). Yvan
  15. Gné ? Pas compris, là... peux-tu donner un exemple de 1er rang pas en haut de la page ? Qu'y a t-il au-dessus ? Edit : je crois que je viens de comprendre... Tu voudrais que, quelle que soit la hauteur de la page, le 1er rang soit toujours visible (même si on utilise l'ascenseur). Il n'y a pas de solution PHP simple (ou alors, il faut gérer la pagination). Il faut taper dans le css et/ou le javascript, car ce que tu demandes se passe du coté client, pas du coté serveur. Yvan