Jump to content
  • 0

CORS header ‘Access-Control-Allow-Origin’ missing - Différence FMS18/FMS19 ?


MagalieJ
 Share

Question

Bonjour à tous !

Nous avons un site web servi via la Data API par une base FileMaker hébergée sur FileMaker Server 18 installée sur macOS 10.13.

J'ai installé un FileMaker Server 19 sur un CentOS 7.9 et j'y ai déposé la même base de données. Alors que tout fonctionne parfaitement lors de la connexion au premier serveur, on obtient une erreur de CORS si on relie le site web au second serveur. La Data API fonctionne par ailleurs parfaitement bien sur le second serveur puisqu'on y accède sans souci via Postman. Avant de me lancer dans la modification des fichiers de configuration de Apache, je voudrais savoir d'où vient la différence (v18 vs v19 ou bien macOS vs Linux ?) et s'il y a moyen de résoudre ça sans mettre le nez dans les conf.

Link to comment
Share on other sites

13 answers to this question

Recommended Posts

  • 0

Effectivement. On a le problème quand on est en "localhost" ou quand on est en "domaineclient.com" sachant que notre serveur FMS est en "fmp.cheznous.fr".

Link to comment
Share on other sites

  • 0

Ceci dit, à terme, on pourrait avoir tout sur domaineclient.com, ce qui résoudrait la question du CORS. Mais est-ce que ça induirait d'autres difficultés ?

Link to comment
Share on other sites

  • 0

Dans tous les cas il faut un peu de configuration, ton hébergeur doit pouvoir faire ça sans trop de problème ;)

Link to comment
Share on other sites

  • 0

Salut Magalie,

Les CORS du web sont un problème au moins aussi gênant que ceux qu'on peut avoir aux pieds.

En fait, il s'agit d'une sécurité qui empêche à un navigateur d'effectuer des requêtes "ajax" (via du code javascript) vers un autre serveur, si ce serveur ne l'a pas explicitement autorisé (exemple page HTML servie sur un serveur A, qui appelle un server B).

Cela veux donc dire (en théorie) que tu devrais ajouter des en-têtes 'CORS' à ton serveur FileMaker pour qu'il autorise les personnes qui se connecte à ton site a faire des requêtes dessus.

Cela ressemble à ca :

Access-Control-Allow-Origin: https://foo.example

MAIS, en pratique, ca ne suffira pas ET je ne te le recommande pas du tout, pour des raisons de sécurité justement (et oui, si ces CORS sont là c'est à cause de ca justement) :

1. Pour vérifier si les 'CORS' sont configurés, le navigateur va faire une première requêtes de type 'OPTION' (requête qui ne renvoi pas de données, seulement les en-tête de réponse)... sauf que le data API ne gère pas ce type de requêtes

2. Cela veux dire que les requêtes sont faites via le navigateur de l'utilisateur et que donc, les identifiants de connexion à ta base de données lui sont donc communiqué ! Et ca, c'est vraiment pas une bonne idée car c'est très facile à récupérer. Quand bien même tu aurais géré la sécurité du compte très finement, cela donne beaucoup trop d'infos à un éventuel hacker qui aura vite fait de faire tomber ton serveur Filemaker.

Je te recommande plutôt de passer par un backend (php, node ?) de ton serveur web pour faire les appels aux data API, cela te permet : 

  • de garder les identifiants filemaker secret
  • de cacher l'adresse du serveur FileMaker

 

Dans tous les cas, je recommande de ne JAMAIS faire de requêtes au dataAPI via le navigateur.

PS : cela fonctionne dans postman car il n'y a pas cette sécurité (ce n'est pas un navigateur)

 

Link to comment
Share on other sites

  • 0

Coucou Romain !

Merci pour ta réponse qui confirme bien ce que je subodorais...

Il y a 11 heures, Airmoi a dit :

MAIS, en pratique, ca ne suffira pas ET je ne te le recommande pas du tout, pour des raisons de sécurité justement (et oui, si ces CORS sont là c'est à cause de ca justement) :

J'ai donc bien fait de ne pas commencer à farfouiller dans les fichiers conf du serveur Apache ! Ça me semblait bien dangereux aussi...

Il y a 11 heures, Airmoi a dit :

Je te recommande plutôt de passer par un backend (php, node ?) de ton serveur web pour faire les appels aux data API, cela te permet : 

  • de garder les identifiants filemaker secret
  • de cacher l'adresse du serveur FileMaker

 

Dans tous les cas, je recommande de ne JAMAIS faire de requêtes au dataAPI via le navigateur.

Merci du conseil, ça peut être très utile !

Et l'idée de mettre le site web directement servi par le serveur Apache de FileMaker Server (ce qui résoudrait le problème des CORS si je ne m'abuse), fausse-bonne idée ?

Link to comment
Share on other sites

  • 0

Si tout est sur le meme serveur, ca va résoudre le problème de CORS, mais pas la question de la sécurité. Du coup je dirais : fausse bonne idée

Link to comment
Share on other sites

  • 0
Le 28/01/2021 à 09:34, Airmoi a dit :

Dans tous les cas, je recommande de ne JAMAIS faire de requêtes au dataAPI via le navigateur.

Ça m'avait titillé effectivement et on a pris l'option d'avoir un petit bout de PHP qui fait la connexion initiale (donc 0 identifiant depuis le navigateur) et transmet le token au navigateur qui, lui, se charge de faire les appels dataAPI en direct.

 

Il y a 16 heures, Airmoi a dit :

Si tout est sur le meme serveur, ca va résoudre le problème de CORS, mais pas la question de la sécurité. Du coup je dirais : fausse bonne idée

Mais alors, on s'en sort comment de ce fichu CORS ??? 🥶

Link to comment
Share on other sites

  • 0

Bonjour

Vos posts me titillent un peu.

Magalie, j'ai essayé de passer par un bout de code PHP pour récupérer le token du DataApi, qui ensuite était envoyé au client. Résultat, quand je faisais une requête en utilisant ce token (à partir du client, cette fois), je me prenais une erreur "token invalide" dans les gencives. J'ai donc viré la couche PHP pour récupérer directement le token à partir de JS, et là je n'ai plus eu aucun problème. J'en avais déduis (probablement de façon erronée) qu'il fallait que l'adresse IP (ou tout autre information envoyée à FMS) soit identique entre la demande de token et l'utilisation dudit token.

Romain, je comprends que te connecter via un compte générique sur la DataApi soit pour le moins dangereux, mais quid d'un compte spécifique par utilisateur ? Si chaque utilisateur de ton appli utilise un login/pw qui lui est propre, et qui correspond à un seul compte coté FM, et chaque compte relié à un profil ayant des droits limités qui vont bien, où est le problème ? Certe cela implique que FM va devoir créer un compte par utilisateur, mais cela semble se faire sans trop de difficulté par script.

 

Accessoirement, content de me retrouver parmi la bande de fous ;)

 

Yvan

Link to comment
Share on other sites

  • 0

Misterrrrrrrr..... Yvan Picot !
Qu'est-ce qu'il s'est passé ? le permafrost où tu étais coincé a dégelé ?
Content de te voir !

Link to comment
Share on other sites

  • 0

Fabrice, comme tu sais, je suis à l'aise avec FM, à condition de ne pas y toucher. Pour moi, tous ces trucs de développeurs... ;) :D

Là j'ai simplement l'occasion de faire un peu de Vue.js, ce qui me change agréablement de PHP (Ca reste moins agréable que Python et d'autres bricoles, mais c'est une autre histoire...). Et comme d'habitude, je suis toujours prêt à partager mon ignorance avec d'autres ;)

 

Yvan

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...