Bienvenue dans le premier volet de ma série « Aujourd'hui, j'ai appris » ! À travers ces articles, je partagerai des informations pratiques acquises au cours de mon travail en tant qu'ingénieur en algorithmes, en approfondissant les techniques que j'ai mises en œuvre pour relever les défis du monde réel. J'espère que ces leçons apporteront également de la valeur à vos projets.
Pour illustrer, je vais passer en revue un projet sur lequel j'ai travaillé impliquant la technologie de reconnaissance faciale, en particulier les étapes nécessaires pour rationaliser le traitement et maintenir les performances entre les utilisateurs.
Dans cet exemple, la tâche consistait à créer une application de reconnaissance faciale (Check in check out system) accessible via un navigateur Web. L'application devait :
L'application est conçue avec deux composants principaux :
Pour simplifier, imaginez que le client détecte et vérifie un visage avant de l'envoyer au serveur, où le serveur renvoie les résultats et que le navigateur les affiche.
Imaginez un utilisateur typique, Alex, qui a récemment commencé à utiliser une nouvelle application Web de reconnaissance faciale pour pointer à l'entrée et à la sortie du travail. Un matin, Alex a décidé d'ouvrir l'application dans quelques onglets du navigateur, pensant pouvoir accélérer son enregistrement en la testant dans plusieurs onglets à la fois.
Presque immédiatement, les choses se sont détériorées. Au fur et à mesure que chaque onglet était chargé, il initialisait indépendamment les processus de détection et de vérification des visages de l’application. Alex a remarqué que son ordinateur ralentissait considérablement et finalement, le navigateur a commencé à prendre du retard. En coulisses, ces multiples onglets utilisaient chacun des ressources pour traiter le visage d'Alex, ce qui affectait grandement les performances de son appareil.
Mais le problème ne s’arrête pas là. Chaque onglet envoyant des demandes de reconnaissance distinctes au serveur, la charge du serveur de l'application a augmenté, entraînant des retards pour les autres utilisateurs se connectant en même temps. Le serveur, submergé de demandes en double, pouvait à peine suivre le rythme, ce qui entraînait des retards et des enregistrements manqués.
Pour rendre les choses encore plus confuses, chaque onglet affichait un statut de connexion différent et incohérent. Alex s'est rapidement rendu compte que l'ouverture de l'application dans plusieurs onglets lui avait causé des maux de tête inutiles et des problèmes potentiels pour l'ensemble de l'entreprise.
Pour garantir une fonctionnalité transparente et éviter une pression inutile sur les ressources client et serveur, nous devions empêcher les utilisateurs d'ouvrir plusieurs onglets avec l'application
L'objectif était d'empêcher les utilisateurs d'ouvrir plusieurs instances de l'application à la fois dans leur navigateur, principalement en détectant lorsque d'autres onglets avec la même application sont déjà ouverts. Voici comment aborder cela :
if (localStorage.getItem('isAppRunning') === 'true') { alert("The application is already open in another tab. Please close this tab."); } else { // Set a flag in localStorage to indicate the app is running localStorage.setItem('isAppRunning', 'true'); // Add an event listener to clear the flag when the tab is closed window.addEventListener('beforeunload', () => { localStorage.removeItem('isAppRunning'); }); // Main function to load models and start video if the app is not running in another tab (async function main() { try { const config = await loadConfig(); // Load models concurrently const [tinyFaceDetector, fasnet, phoneDetect] = await Promise.all([ loadTinyFaceDetector(), loadFasnet(config), loadPhoneDetect(config), ]); Object.assign(window, { fasnet, phoneDetect, config }); startVideo(); } catch (err) { console.error('Initialization failed:', err); } })(); }
Dans notre système de reconnaissance faciale, l'exigence a évolué pour autoriser uniquement l'accès autorisé spécifique à un service. Par exemple, si la personne A appartient au service A, elle ne devrait pouvoir s'enregistrer ou sortir que sur les appareils du réseau du service A, et non sur le service B ou tout autre service. Étant donné que ces ordinateurs sont connectés via un réseau local (LAN), nous avons besoin d'un moyen d'identifier et de restreindre l'accès en fonction de l'adresse IP de l'appareil
Lorsque j'ai effectué une recherche en ligne, j'ai obtenu des informations sur l'obtention de l'adresse IP. Mais ils ont quelques problèmes
function user_location() { var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { console.log( this.responseText); } }; xhttp.open("GET", "//api.ipify.org?format=json", true); xhttp.send(); }
Cette fonction récupère avec succès l’adresse IP publique de l’utilisateur ; cependant, il ne fournit pas l'adresse IP LAN interne requise pour le contrôle d'accès spécifique au service. De plus, il est susceptible d'être masqué par les VPN ou les pare-feu.
ou peut-être celui-ci
Firefox et Chrome ont implémenté WebRTC qui permet d'envoyer des requêtes aux serveurs STUN qui renverront les adresses IP locales et publiques de l'utilisateur
Mais je ne veux pas ajouter plus de packages dans mon application. Cette complexité, combinée à d'éventuelles incohérences entre navigateurs, le rend moins souhaitable.
Puis j'ai trouvé ce post
Récupérer l'adresse IP d'un client directement avec JavaScript exécuté dans le navigateur n'est pas simple. En effet, JavaScript n'a pas accès à la couche réseau où les adresses IP sont exposées. De plus, pour des raisons de sécurité, les navigateurs sandboxent l'environnement JavaScript, l'empêchant d'accéder à certaines informations au niveau du système, notamment l'adresse IP du client.
Il s'avère que récupérer l'adresse IP uniquement avec JavaScript n'est pas réalisable. Cependant, il existe une solution simple : créer un point de terminaison API sur le serveur pour obtenir l'adresse IP de l'utilisateur.
if (localStorage.getItem('isAppRunning') === 'true') { alert("The application is already open in another tab. Please close this tab."); } else { // Set a flag in localStorage to indicate the app is running localStorage.setItem('isAppRunning', 'true'); // Add an event listener to clear the flag when the tab is closed window.addEventListener('beforeunload', () => { localStorage.removeItem('isAppRunning'); }); // Main function to load models and start video if the app is not running in another tab (async function main() { try { const config = await loadConfig(); // Load models concurrently const [tinyFaceDetector, fasnet, phoneDetect] = await Promise.all([ loadTinyFaceDetector(), loadFasnet(config), loadPhoneDetect(config), ]); Object.assign(window, { fasnet, phoneDetect, config }); startVideo(); } catch (err) { console.error('Initialization failed:', err); } })(); }
Lorsqu'un client fait une demande, Flask remplit automatiquement l'objet de demande avec divers en-têtes et détails de connexion.
Tout d'abord, le code vérifie l'en-tête X-Forwarded-For avec client_ip = request.headers.get('X-Forwarded-For').
Objectif : cet en-tête est généralement défini par des proxys ou des équilibreurs de charge pour conserver l'adresse IP d'origine du client. Si la demande a transité via un proxy ou un équilibreur de charge, l'adresse IP réelle du client doit apparaître dans cet en-tête.
Si l'en-tête X-Forwarded-For est trouvé, client_ip est défini sur sa valeur.
Si l'en-tête X-Forwarded-For est manquant (par exemple, si le client se connecte directement sans proxy), le code utilise request.remote_addr pour obtenir l'adresse IP directement du client.
Dans cet article, je partage mes expériences face aux défis du monde réel liés au développement d'une application Web de reconnaissance faciale. Voici deux problèmes clés que nous avons résolus :
Empêcher les instances d'onglets multiples : pour empêcher les utilisateurs d'ouvrir l'application dans plusieurs onglets du navigateur, nous utilisons localStorage pour savoir si l'application est déjà ouverte. Cela évite les processus de détection de visage redondants qui sollicitent à la fois les ressources du client et du serveur.
Récupération de l'adresse IP de l'utilisateur : étant donné que JavaScript ne peut pas accéder directement à l'adresse IP LAN d'un appareil en raison de limitations de sécurité, nous avons configuré un point de terminaison API sur le serveur pour obtenir l'adresse IP à partir des en-têtes de requête. Cette approche garantit un contrôle d'accès spécifique au service pour les appareils autorisés uniquement.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!