java - google - modifier meta description wordpress



Jouer le cadre. La session devient nulle après la redirection depuis la page de connexion google (1)

J'essaye d'incorporer le graphique de google analytics à l'application Web pour montrer des statistiques d'utilisateur de leurs utilisations d'application. Ceci est l'URL locale http://192.168.100.10:9000/ je http://192.168.100.10:9000/ connecte au tableau de bord (application web) J'ai un bouton de connexion google. Jusqu'à présent, je maintiens la session de l'utilisateur après quand il se connecte.

Et lorsque l'utilisateur clique sur le bouton de connexion. Il déclenche la méthode de rappel. Lorsque le rappel est déclenché la première fois, la session est maintenue. Je veux dire session("user") n'est pas nulle ici.

public Result callback() {
    JsonNode jsonNode = Json.parse(session("user"));
    UserDTO userDTO = Json.fromJson(jsonNode, UserDTO.class);

    if (userDTO.getRole().getType().equals(RoleDTO.EnRoleType.ADMIN.toString()))
        return redirect(com.softoven.ultron.controllers.routes.AccountCTRL.index());
    if (request().queryString().get("code") != null && request().queryString().get("state") != null && request().queryString().get("state")[0].equals(session("state"))) { // Check if he/she is authorized
        session().remove("state");
        Analytics analytics = setAnalytics(userDTO, request());
        session("analytics", Json.toJson(analytics).toString());
        return redirect(com.softoven.ultron.controllers.routes.AccountCTRL.index());
    } else {  // Create Authorization URL
        String url = helper.buildLoginUrl();
        session("state", helper.getStateToken());
        return redirect(url);
    }
}

Il s'agit de l'URL lorsque l'utilisateur clique sur le bouton de connexion https://accounts.google.com/o/oauth2/auth?access_type=offline&approval_prompt=force&client_id=784122128025-cvq0fn1e23f24dia4soavsd9v1ovesub.apps.googleusercontent.com&redirect_uri=http://localhost:9000/callback&response_type=code&scope=https://www.googleapis.com/auth/analytics.readonly%20https://www.googleapis.com/auth/analytics.manage.users%20https://www.googleapis.com/auth/analytics%20https://www.googleapis.com/auth/analytics.edit%20https://www.googleapis.com/auth/analytics.manage.users.readonly%20https://www.googleapis.com/auth/analytics.provision&state=google-35808300 Et lorsque l'utilisateur clique sur le bouton allow sur la page d'autorisation de la connexion google, le contrôle revient à callback()

mais cette session("user") temps session("user") est nulle. ce qui ne devrait pas être nul parce que j'avais défini la session lorsque l'utilisateur s'est connecté. Je ne sais pas pourquoi cela se passe et comment y remédier.

Et ceci est l'URL de fin après la redirection de la page d'autorisation google. http: // localhost: 9000 / rappel? état = google-35808300 & code = 4 / g-FkJ3GGS01jbeXLHK0o95ks-K-drGK7bxgzvi3cELU #


Ceci est l'URL locale http://192.168.100.10:9000/ ...

... & redirect_uri = http: // localhost: 9000 / ...

Et ceci est l'URL de fin après la redirection de la page d'autorisation google http: // localhost: 9000 / ...

L'URL de départ est différente de l'URL de fin. Ce n'est pas correct.

Normalement, la session HTTP côté serveur est liée à un cookie de session. Les cookies sont à leur tour liés à un nom d'hôte spécifique (IP ou domaine). Les webbrowsers sont très stricts dans l'envoi de cookies au nom d'hôte spécifique. Même si l'adresse IP résout le domaine DNS correctement, les navigateurs Web peuvent refuser d'envoyer le cookie créé sur une adresse IP avec une requête sur le nom de domaine. Fondamentalement, le serveur Web ne récupérera pas le cookie de session créé à l'origine et en crée donc un nouveau.

Ensuite, il existe des webbrowsers qui rejettent les cookies dont le nom d'hôte est explicitement défini sur "localhost", tel que Google Chrome: Chrome ne crée pas de cookie pour domain = localhost en https brisé . Les navigateurs peuvent également choisir de rejeter les cookies dont le nom d'hôte est explicitement défini sur une adresse IP car cela peut provoquer des problèmes de sécurité lorsque le client utilise une adresse IP dynamique.

Il est donc fortement recommandé d'utiliser un nom de domaine réel tel que example.com au lieu d'une adresse IP ou "localhost". Sans en acheter un, vous pouvez en truquer un en éditant simplement le fichier hosts . Le format de chaque ligne est comme ci-dessous, d'abord les adresses IP et ensuite l'espace des domaines souhaité séparé.

127.0.0.1 localhost example.com anotherexample.com

Ensuite, utilisez toujours exactement ce domaine tout au long du processus. Commencez par http://example.com:9000/... , utilisez &redirect_uri=http://example.com:9000/... etc.

Je ne fais pas Play Framework, mais si vous êtes familier avec l'API Servlet, vous pouvez mieux comprendre le fonctionnement de la session HTTP après avoir lu cette FAQ : Comment fonctionnent les servlets? Instanciation, sessions, variables partagées et multithreading .





playframework-2.0