Questions d'entretien courantes sur Java Web

Quelle est la différence entre jsp et servlet ? (Apprentissage recommandé : Questions de test communes Java )

JSP devient un service (l'essence de JSP est le service, jvm ne peut reconnaître que les catégories Java, non. Reconnaître le code JSP et le Web. le conteneur compile le code JSP dans une classe Java qui peut être reconnue par la JVM)

JSP est meilleur pour l'affichage des pages et le servlet est meilleur pour le contrôle logique.

Il n'y a pas d'objets intégrés dans Servlet. Les objets intégrés dans Jsp doivent être obtenus via l'objet HttpServletRequest, l'objet HttpServletResponse et l'objet HttpServlet.

Jsp est une simplification de Servlet. L'utilisation de Jsp ne nécessite que de compléter le contenu que le programmeur doit envoyer au client. La façon d'intégrer le script Java dans Jsp dans une classe est complétée par le conteneur Jsp. Servlet est une classe Java complète et la méthode Service de cette classe est utilisée pour générer une réponse au client.

Quels sont les objets intégrés de jsp ? Quelles sont les fonctions ?

JSP possède 9 objets intégrés :

request : encapsule la requête du client, qui contient les paramètres de la requête GET ou POST

response : encapsule la réponse du serveur au client ;

pageContext : d'autres objets peuvent être obtenus via cet objet

session : un objet qui encapsule la session utilisateur ; >application : encapsule le serveur L'objet de l'environnement d'exécution ;

out : l'objet de flux de sortie de la réponse du serveur de sortie ;

config : l'objet de configuration de l'application Web ;

page : la page JSP elle-même (équivalent à Java ceci dans le programme) ;

exception : un objet qui encapsule l'exception levée par la page.

Parlez-moi des quatre portées de jsp ?

Les quatre portées dans JSP incluent la page, la requête, la session et l'application. Plus précisément :

page représente les objets liés à une page et à une propriété.

request représente les objets et propriétés liés à une requête émise par le client Web. Une requête peut s'étendre sur plusieurs pages et impliquer plusieurs composants Web ; les données temporaires qui doivent être affichées sur la page peuvent être placées dans cette étendue.

session représente les objets et attributs liés à une session établie par un utilisateur et le serveur. Les données relatives à un utilisateur doivent être placées dans la propre session de l'utilisateur.

l'application représente des objets et des propriétés liés à l'ensemble de l'application Web. Il s'agit essentiellement d'une portée globale qui couvre l'ensemble de l'application Web, y compris plusieurs pages, requêtes et sessions.

Quelle est la différence entre une session et un cookie ?

Étant donné que le protocole HTTP est un protocole sans état, lorsque le serveur doit enregistrer le statut de l'utilisateur, il doit utiliser un mécanisme pour identifier l'utilisateur spécifique. Ce mécanisme est des scénarios typiques tels que les achats. Car, lorsque vous cliquez sur le bouton de commande, puisque le protocole HTTP est apatride, il ne sait pas quel utilisateur l'a exploité, le serveur doit donc créer une session spécifique pour l'utilisateur spécifique afin d'identifier l'utilisateur et de le suivre, de sorte que. vous savez combien de livres il y a dans le panier.

Cette Session est enregistrée sur le serveur et possède un identifiant unique. Il existe de nombreuses façons d'enregistrer une session côté serveur, notamment la mémoire, la base de données et les fichiers.

Le transfert de session doit également être pris en compte lors du clustering. Dans les grands sites Web, il existe généralement un cluster de serveurs de session dédié pour enregistrer les sessions utilisateur. À ce stade, les informations de session sont placées en mémoire et certains caches sont utilisés. car Memcached sont utilisés pour stocker les sessions.

Pensez à la façon dont le serveur identifie un client spécifique ?

C'est à ce moment-là que Cookie apparaît. Chaque fois qu'une requête HTTP est effectuée, le client enverra les informations de cookie correspondantes au serveur. En fait, la plupart des applications utilisent des cookies pour mettre en œuvre le suivi de session. Lorsqu'une session est créée pour la première fois, le serveur indiquera au client dans le protocole HTTP qu'un identifiant de session doit être enregistré dans le cookie. Celui-ci sera enregistré pour chaque. demande ultérieure. L'ID de session est envoyé au serveur et je sais qui vous êtes.

Quelqu'un a demandé : que se passe-t-il si le navigateur du client désactive les cookies ?

Généralement dans ce cas, une technologie appelée réécriture d'URL est utilisée pour le suivi de session, c'est-à-dire que pour chaque interaction HTTP, un paramètre tel que sid=xxxxx sera ajouté à l'URL du serveur. l'utilise pour identifier l'utilisateur.

Les cookies peuvent en fait être utilisés dans certains scénarios conviviaux. Imaginez que vous vous êtes connecté une fois à un site Web et que vous ne souhaitez plus accéder à votre compte la prochaine fois que vous vous connectez. faire?

Ces informations peuvent être écrites dans le cookie. Lors de la visite du site Web, le script de la page du site Web peut lire ces informations et remplir automatiquement le nom d'utilisateur pour vous, ce qui peut faciliter l'utilisateur. C'est aussi l'origine du nom du cookie, une petite douceur pour les utilisateurs.

Donc, pour résumer :

La session est une structure de données enregistrée sur le serveur pour suivre l'état de l'utilisateur. Ces données peuvent être enregistrées dans le cluster, la base de données, dans. le fichier

Le cookie est un mécanisme permettant au client de sauvegarder les informations de l'utilisateur. Il est utilisé pour enregistrer certaines informations de l'utilisateur et constitue également un moyen de mettre en œuvre une session.

Dites-moi comment se déroule la séance ?

En fait, session est un fichier similaire à une table de hachage qui existe sur le serveur. Les informations dont nous avons besoin y sont stockées et nous pouvons les extraire lorsque nous en avons besoin.

C'est similaire à une grande carte. La clé à l'intérieur stocke l'identifiant de session de l'utilisateur. L'utilisateur apportera cet identifiant de session lors de l'envoi d'une requête au serveur. A ce moment, la valeur correspondante peut en être extraite.

Si le client désactive les cookies, la session peut-elle toujours être utilisée ?

Cookie et Session sont généralement considérés comme deux choses indépendantes. Session utilise une solution qui maintient l'état côté serveur, tandis que Cookie utilise une solution qui maintient l'état côté client.

Mais pourquoi ne puis-je pas obtenir de session si je désactive les cookies ?

Étant donné que la session utilise l'ID de session pour déterminer la session du serveur correspondant à la conversation en cours et que l'ID de session est transmis via Cookie, la désactivation de Cookie équivaut à perdre l'ID de session, et donc à ne pas obtenir la Séance.

Supposons que l'utilisateur utilise Session lorsque les cookies sont désactivés. Il existe plusieurs façons d'y parvenir :

Définissez "session.use_trans_sid = 1 dans le php.ini. configuration file ", ou activez l'option "--enable-trans-sid" lors de la compilation pour permettre à PHP de transmettre automatiquement l'ID de session entre les pages.

Transmettez manuellement la valeur via l'URL et transmettez l'ID de session via le formulaire masqué.

Enregistrez l'ID de session dans un fichier, une base de données, etc., et appelez-le manuellement pendant le processus interpage.

Quelle est la différence entre le ressort mvc et les jambes de force ?

Différences dans les mécanismes d'interception

Struts2 est une interception au niveau de la classe Chaque requête créera une action lors de l'intégration avec Spring, Struts2 ActionBean. la portée d'injection est le prototype du mode prototype, puis les données de la demande sont injectées dans l'attribut via le setter et le getter.

Dans Struts2, une action correspond à un contexte de requête et de réponse. Lors de la réception de paramètres, elle peut être reçue via des attributs. Cela montre que les paramètres d'attribut sont partagés par plusieurs méthodes.

Une méthode Action dans Struts2 peut correspondre à une URL, mais ses attributs de classe sont partagés par toutes les méthodes, ce qui rend impossible l'utilisation d'annotations ou d'autres méthodes pour identifier sa méthode, et ne peut être conçue que comme multiple. cas.

SpringMVC est une interception au niveau de la méthode. Une méthode correspond à un contexte de requête, la méthode est donc fondamentalement indépendante et a un accès exclusif aux données de requête et de réponse. Chaque méthode correspond à une URL à la fois. Le paramètre passé est directement injecté dans la méthode, ce qui est unique à la méthode. Les résultats du traitement sont renvoyés au framework via ModeMap.

Pendant l'intégration de Spring, le Controller Bean de SpringMVC est par défaut en mode Singleton, donc par défaut, un seul contrôleur sera créé pour toutes les requêtes. Il ne devrait y avoir aucun attribut partagé, il est donc thread-safe si vous souhaitez le modifier. la portée par défaut, vous devez ajouter la modification de l'annotation @Scope.

Struts2 possède son propre mécanisme d'interception. SpringMVC utilise une méthode Aop indépendante, ce qui fait que la quantité de fichiers de configuration de Struts2 est plus grande que celle de SpringMVC.

Différences dans les frameworks sous-jacents

Struts2 est implémenté à l'aide de Filter (StrutsPrepareAndExecuteFilter), tandis que SpringMVC (DispatcherServlet) est implémenté à l'aide de Servlet. Le filtre est initialisé après le démarrage du conteneur ; il plante après l'arrêt du service, plus tard que le Servlet. Le servlet est initialisé lors de son appel, avant l'appel de Filter, et est détruit après l'arrêt du service.

En termes de performances

Struts2 est une interception au niveau de la classe Chaque requête correspond à une nouvelle action pour l'instance, et toutes les injections de valeurs d'attribut doivent être chargées. SpringMVC implémente une configuration nulle, en raison de l'interception basée sur la méthode de SpringMVC, l'injection du bean en mode singleton est chargée une fois. Par conséquent, l’efficacité et les performances du développement SpringMVC sont supérieures à celles de Struts2.

En termes de configuration

spring MVC et Spring sont transparents. La gestion et la sécurité de ce projet sont également supérieures à celles de Struts2.

Comment éviter l'injection SQL ?

PreparedStatement (méthode simple et efficace)

Utiliser des expressions régulières pour filtrer les paramètres entrants

Filtrage de chaînes

Appel en JSP Cette fonction vérifie si il contient des caractères illégaux

Code de jugement de page JSP

Qu'est-ce qu'une attaque XSS et comment l'éviter ?

L'attaque XSS est également appelée CSS, le nom complet est Cross Site Script (attaque de script intersite). Le principe est que l'attaquant entre du code HTML malveillant dans un site Web présentant des vulnérabilités XSS. Lorsque l'utilisateur navigue sur le site Web, ce code HTML sera automatiquement exécuté pour atteindre l'objectif de l'attaque.

Les attaques XSS sont similaires aux attaques par injection SQL. Dans les attaques par injection SQL, les instructions SQL sont utilisées comme entrée utilisateur pour interroger/modifier/supprimer des données. Dans les attaques XSS, des scripts malveillants sont insérés pour cibler le contrôle du navigateur. obtenir des informations sur l'utilisateur. XSS est une vulnérabilité courante dans les programmes Web. XSS est une méthode d'attaque passive utilisée côté client.

L'idée générale de la prévention XSS est la suivante : filtrer l'entrée (et les paramètres d'URL) et encoder la sortie.

Qu'est-ce qu'une attaque CSRF et comment l'éviter ?

CSRF (Cross-site request falsification) est également appelé attaque en un clic ou session riding. Le nom chinois complet est cross-site request falsification. D'une manière générale, l'attaquant falsifie la requête du navigateur de l'utilisateur et l'envoie à un site Web que l'utilisateur s'est authentifié pour visiter, de sorte que le site Web cible reçoit et pense à tort qu'il s'agit de l'opération réelle de l'utilisateur et exécute la commande.

Couramment utilisé pour voler des comptes, transférer de l'argent, envoyer de faux messages, etc. L'attaquant exploite la vulnérabilité de vérification des demandes du site Web pour mettre en œuvre une telle attaque. Le site Web peut confirmer que la demande provient du navigateur de l'utilisateur, mais ne peut pas vérifier si la demande provient de la véritable intention de l'utilisateur.

Comment éviter :

1. Vérifiez le champ HTTP Referer

Le champ Referer dans l'en-tête HTTP enregistre le Adresse source de la requête HTTP. Dans des circonstances normales, la demande d'accès à une page sécurisée et restreinte provient du même site Web, et si un pirate informatique souhaite mettre en œuvre une attaque CSRF

, il ne peut généralement construire la demande que sur son propre site Web. Par conséquent, les attaques CSRF peuvent être défendues en vérifiant la valeur Referer.

2. Utiliser le code de vérification

Ajouter le code de vérification à la page d'opération clé Après avoir reçu la demande, l'arrière-plan peut juger le code de vérification pour empêcher CSRF. Mais cette méthode n’est pas très conviviale.

3. Ajoutez un jeton à l'adresse de la demande et vérifiez

La raison pour laquelle l'attaque CSRF réussit est que le pirate informatique peut complètement falsifier la demande de l'utilisateur, et tout le reste. Les informations de vérification de l'utilisateur existent dans les cookies, de sorte que les pirates peuvent directement utiliser les propres cookies de l'utilisateur pour passer la vérification de sécurité sans connaître les informations de vérification. La clé pour résister au CSRF est d’insérer dans la demande des informations que les pirates ne peuvent pas falsifier et que ces informations n’existent pas dans les cookies.

Vous pouvez ajouter un jeton généré aléatoirement en tant que paramètre dans la requête HTTP et créer un intercepteur côté serveur pour vérifier le jeton dans la requête ou si le contenu du jeton est incorrect. est considéré comme possible. La demande est rejetée en raison d'une attaque CSRF.

Cette méthode est plus sûre que la vérification du référent. Le jeton peut être généré une fois que l'utilisateur s'est connecté et placé dans la session. Ensuite, le jeton peut être retiré de la session à chaque demande et mis en correspondance avec le jeton présent. la requête. Comparez, mais la difficulté de cette méthode est de savoir comment ajouter le jeton à la requête sous forme de paramètres.

Pour les requêtes GET, le jeton sera ajouté à l'adresse de la requête, de sorte que l'URL devienne http://url?csrftoken=tokenvalue.

Pour les requêtes POST, ajoutez à la fin du formulaire, pour que le token soit sous la forme d'un paramètre Demandé à rejoindre.

4. Personnalisez les attributs dans l'en-tête HTTP et vérifiez

Cette méthode utilise également des jetons pour la vérification. La différence avec la méthode précédente est qu'il n'y a pas de lieu de mise. le jeton en tant que paramètre dans la requête HTTP, placez-le dans un attribut personnalisé dans l'en-tête HTTP.

Grâce à la classe XMLHttpRequest, vous pouvez ajouter l'attribut d'en-tête HTTP csrftoken à toutes les requêtes de ce type à la fois et y mettre la valeur du jeton.

Cela résout l'inconvénient de l'ajout d'un jeton à la requête dans la méthode précédente. Dans le même temps, l'adresse demandée via XMLHttpRequest ne sera pas enregistrée dans la barre d'adresse du navigateur et il n'y a pas lieu de s'inquiéter de la question. le jeton est divulgué sur d'autres sites Web via le référent.

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!