Spring Sessions sind null

danielmaann

Mitglied
Hallo zusammen

Ich schreibe aktuell einen Webservice welcher später für andere Applikationen eingesetzt wird.
Als Framework wird Spring verwendet und beim Webservice handelt es sich um eine Springboot Applikation. Nun...

Sobald sich der Benutzer auf eine Applikation einloggt welche mit dem Webservice kommuniziert, sollte es für den Benutzer eine Session auf dem Webservice starten.

Nun besteht folgendes Problem:
Beim erstellen von der Session funktioniert alles und die Session ist gesetzt, jedoch wird bei einem zweiten Request von diesem Benutzer, ein NULL zurück gegeben so als ob diese Session gar nicht vorhanden wäre... Wehslab? Was habe ich nicht beachtet? PS. ich arbeite nicht mit dem Redis.

Java:
@RequestMapping(value = "/login", method = RequestMethod.POST)
    public String login(@RequestParam("email") String email, @RequestParam("password") String password, HttpServletRequest request) {
        String resultString = "{\"error\":\"true\",\"intend\":\"login\"}";
     
        if(authValidator.checkEmail(email) && authValidator.checkPassword(password)){
            resultString = userHandler.login(email, password).toString();
            gson = new Gson();
            User user = gson.fromJson(resultString, User.class);
            if (!user.isError() && "1".equals(user.getAgb())) {
                String token = UUID.randomUUID().toString(); // token wird benötigt für doppelte Logins
                System.out.println(sessionHandlerImpl.existSessionWithToken(request, user.getUid(), token)); // gibt TRUE zurück
                resultString = sessionHandlerImpl.getStoredProfile(request, user.getUid()); // gibt auch den richtigen String zurück
            }
        }
        return resultString;
    }

Java:
@RequestMapping(value = "/user", method = RequestMethod.GET)
    public String getUserPage(ModelMap model, HttpServletRequest request, HttpServletResponse response) {
        String myUid = request.getParameter("userId");
        String suid = isNotEmpty(request.getParameter("sUid")) ? request.getParameter("sUid") : myUid; 
        String token = request.getParameter("token");
     
        String resultProfile = "{\"error\":true,\"username\":\"\",\"name\":\"\",\"description\":\"\",\"profilepicture\":\"\",\"following\":\"\",\"intend\":\"get user page\"}";
        sessionHandlerImpl.existSessionWithToken(request, myUid, token); // gibt FALSE zurück
        if (sessionHandlerImpl.existSessionWithToken(request, myUid, token)) {
            if (isNotEmpty(myUid)){
                if (authValidator.checkUserId(myUid)) {
                    if (sessionHandlerImpl.existSession(request, suid)) {
                        resultProfile = sessionHandlerImpl.getStoredProfile(request, suid);
                    } else if (myUid.equals(suid)) {
                        resultProfile = userHandler.getMyUserPage(myUid);
                    } else if (authValidator.checkUserId(suid)) {
                        resultProfile = userHandler.getUserPage(myUid, suid);
                    }
                }
            }
        } else {
            response.setStatus(403);
        }
        return resultProfile;
    }

der zweite block wird nach dem login ausgeführt...


Java:
    public void createSession(HttpServletRequest request, String token, String jsonUserObj) {
        gson = new Gson();
        User user = gson.fromJson(jsonUserObj, User.class);
        user.setToken(token);
        request.getSession().setAttribute(user.getUid(), user);
    }


    public boolean existSessionWithToken(HttpServletRequest request, String userId, String token) {
        try {
            User user = (User) request.getSession(false).getAttribute(userId);
            return user.getToken().equals(token);
        } catch(NullPointerException e) {
            return false;
        }
     
    }

Danke schon mal für die hilfe
 

sascha-sphw

Top Contributor
Ich habe mir jetzt den Code noch nicht im Detail angesehen, aber es hört sich für mich so an, als ob beim 2. Request die SessionID vom Benutzer nicht mitgeschickt wird.

Zudem würde ich noch gerne anmerken, dass es sich bewährt hat, dass man einen Service Stateless aufbaut.
 

danielmaann

Mitglied
@sascha-sphw
wie kann ich die sessionId midt schicken, wird die nicht selbst einfach mitgeschickt im RequestHeader? also ich meine die SessionId? Dachte die ist ein automatischer bestandteil eines requests?

Zu deiner anmerkung, was bedeuted jetzt da stateless? also welcher teil ist stateless? kenne diesen begriff in der SW gar nicht
 

sascha-sphw

Top Contributor
wie kann ich die sessionId midt schicken, wird die nicht selbst einfach mitgeschickt im RequestHeader? also ich meine die SessionId? Dachte die ist ein automatischer bestandteil eines requests?

Die Session ID wird vom Server im Header an den Client geliefert (Set-Cookie: JSESSIONID=405E20BF2689B7CA0790F2DB27F5AA2F). Der Browser würde die ID somit als Cookies speichern und schickt sie automatisch bei jedem weiteren Request wieder mit zum Server. Und meine Vermutung ist jetzt, dass das bei Deinem Client nicht der Fall ist. Ich würde hier einfach mal den Request sniffen und schauen ob das der Fall ist.

Zu deiner anmerkung, was bedeuted jetzt da stateless? also welcher teil ist stateless? kenne diesen begriff in der SW gar nicht

Wiki (https://de.wikipedia.org/wiki/Zustandslosigkeit) sagt. Und damit meinte ich den kompletten Service.
In der Informatik bezeichnet Zustandslosigkeit die Eigenschaft eines Protokolls oder Systems, mehrere Anfragen – auch desselben Auftraggebers – grundsätzlich als voneinander unabhängige Transaktionen zu behandeln. Insbesondere werden Anfragen ohne Bezug zu früheren Anfragen behandelt und keine Sitzungsinformationen ausgetauscht und/oder verwaltet.
 

danielmaann

Mitglied
@sascha-sphw
also werde ihn mal sniffen... kenne die sessions eigendlich nur von PHP aus, habe mit Java nie mit Sessions gearbeitet. Dies ist zum erstenmal der Fall.

Der Web-Service ist halt eine Java-Applikation aber zum Testen benutze ich als ClientApplikation eine PHP-Page welche die Requests absendet und kontrolliert ob die erwarteten daten zurück kommen.


Bezüglich der Zustandaslosigkeit, dies möchte ich ja nun mit den Sessions ablösen damit ich durch jeden Request den Zustand überprüfen kann (ob der Benutzer eingeloggt ist oder nicht)

wieso sollte es aber stateless sein? Man sollte ja übrprüfen ob ein benutzer eigeloggt ist oder nicht? sonst können request abgesetzt werden von bestimmten benutzen die nicht eingeloggt sind.
 

danielmaann

Mitglied
@sascha-sphw

habe mich zu dem OAuth2 eingelesen und finde diesen ansatz ziemlich bescheuert... sehe ich das richtig, dass folgendes passiert:
1. Daten werden einer URL mitgegeben (consumer-key, timestamp, callbackurl,...) z.B. bei login
2. da wird etwas gemacht und dann redirected zu der callback url
3. User möchte profil beabbeiten nun passiert das selbe nur via andere callback URL somit wird wieder der benutzer "eingeloggt" oder ja überprüft ob die login daten korrekt sind bevor die 2. methode ausgeführt wird.

Dies löst ja aus das es pro einfachen Use-Case mehrere Abfragen gibt (jedesmal wird überprüft ob die credentials richtig sind) statt dies in eine session zu packen. dieser ansatz kostte ja deutlich mehr ressourcen oder nicht?
 

sascha-sphw

Top Contributor
@sascha-sphw

habe mich zu dem OAuth2 eingelesen und finde diesen ansatz ziemlich bescheuert... sehe ich das richtig, dass folgendes passiert:
1. Daten werden einer URL mitgegeben (consumer-key, timestamp, callbackurl,...) z.B. bei login
2. da wird etwas gemacht und dann redirected zu der callback url
3. User möchte profil beabbeiten nun passiert das selbe nur via andere callback URL somit wird wieder der benutzer "eingeloggt" oder ja überprüft ob die login daten korrekt sind bevor die 2. methode ausgeführt wird.

Dies löst ja aus das es pro einfachen Use-Case mehrere Abfragen gibt (jedesmal wird überprüft ob die credentials richtig sind) statt dies in eine session zu packen. dieser ansatz kostte ja deutlich mehr ressourcen oder nicht?

Wenn Du das so interpretierst, solltest Du es evtl. noch einmal lesen. Dieser Login Prozess muss nur einmal gemacht werden, danach hast Du den Access Token und alles geht weiterhin mit nur einem Request.
Aber ich will Dir hier nichts aufschwatzen OAuth2 war nur ein Beispiel wie man das mit Token machen kann. Wegen mir musst Du es auch nicht Stateless machen, hab nur erwähnen wollen das RESTful Services normalerweise Stateless sind.

Aber mal zurück zu Deinem eigentlichen Problem, hast Du den Request bereits angesehen? Ist Die Session ID enthalten?
 

danielmaann

Mitglied
@sascha-sphw
ja habe es nun auch begriffen aber dieser vorgang ist ziemlich kompliziert und dafür wird angeblich extra ein server gebraucht nur für die tokens sache .. gibt ja den owner den server und noch eine dritte instanz wo für das OAuth2 benötigt wird... habe mich gestern den ganzen Tag damit beschäftigt aber kann mir kein Bild machen wie das funktionieren soll bzw. wie ich das einsetzten soll da ich nichtmals anständige Examples gefunden habe und die Examples für Spring boot funktionieren nicht einmal.. die werfen schnell mal exceptions... naja .. ich möchte eben die beste und performanteste lösung da der Webservice dann auch kommerziel verwendet werden soll und nicht nur als übung dient.

Nein konnte da nichts herausfinden da meine Clientseitige Applikation eine PHP applikation ist (benutze PHP um dern Webservice zu testen und wenn alles rund läuft wird dann eine Android App entwicklet welche auf diesen Webservice kommuniziert) kann ich ja it den vorhandenen session methoden nur eigene Sessions von php neu generieren und nicht die gekriegte Session id heraus finden? ich habe gestern auch nach der lösung gesucht aber war nicht fündig.
 

danielmaann

Mitglied
@sascha-sphw

beim überprüfen vom request header sind die beiden JSESSIONID Werte gleich von beiden requests und die XSRF-Tokens ebenfalls aber die Session wird nicht gefunden... weshalb nicht?

PS mir ist aufgefallen das der aufruf dieser methode nach dem erzeugen der session session.getId() nicht den selben wert hat wie wenn ich auf der clientseite den header auslese und die JSessionId anzeige ... da sind unterschiedliche werte, weshalb?
 
Zuletzt bearbeitet:

sascha-sphw

Top Contributor
Ich kenne Spring nicht im Detail. Erstellt Spring eine eigene Session?

Ansonsten kann ich nur noch anbieten, dass Du mal ein Minimal-beispiel aufbaust und es mir zum Debuggen hochlädtst.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
R JSF Sessions invalidieren Web Tier 2
X JSF - eine Liste aller Sessions, Instanzen bzwFacesContexte bekommen? Web Tier 4
D JSF Inaktive Sessions bei Datenbankzugriff Web Tier 5
I Sessions werden ungewollt automatisch erzeugt??? Web Tier 3
T Fehler - Unable to restore sessions Web Tier 3
D client-seitige Sessions mit Servlets Web Tier 5
G Daten von ablaufenden Sessions speichern? Web Tier 3
G JSF und Sessions Web Tier 3
R Wie sicher sind Cookies? Web Tier 6
F Wo und wie Daten die für alle Benutzer bestimmt sind verwalten Web Tier 4
M JSF Wie zählt man die User die online sind? Web Tier 5
I Ständige Überprüfung, ob neue Nachrichten vorhanden sind Web Tier 5
S PathParam null Web Tier 5
L Set<T> Attribut eines Objektes wird zu null in thymeleaf Web Tier 2
R getParameter() liefert null Web Tier 6
G JSF JSF 2.3 Converter injection/persistence context -> null Web Tier 2
FINF_AW_Alex Bin ich jetzt bekloppt?!? / Property not found (resolved tu null) Web Tier 5
S value auf null setzen Web Tier 3
J JSF BigInteger nicht null sondern 0 Web Tier 3
J Nach SVN-Update alle Beans resolved to null Web Tier 3
J facesContext ist null bei seam-Projekt Web Tier 3
T getParameter("id") = null - warum? Web Tier 8
D JSF EL #{not null bean.property} Parse exception Web Tier 2
B JSF,JPA = [ id=null ] is not a known entity type. Web Tier 3
G Servlet getSession(false) in HttpServletRequest gibt nie null zurück Web Tier 3
J JSF/CDI - Target Unreachable, identifier 'user' resolved to null Web Tier 5
P JSF Formularwert null Web Tier 10
P FacesContext.getCurrentInstance () liefert Null Web Tier 6
T Seam-Projekt Eingabefeld mit "null"-Wert Web Tier 7
H facestrace - null pointer exception Web Tier 3
G Tomahawk FileUpload UploadedFile ist null Web Tier 4

Ähnliche Java Themen

Neue Themen


Oben