I am building a service which would depend on maintaining a unique session ID for the connected clients. Currently I am using the login() method to return sessionID as a part of userData from deepstream authentication handler.
When a client(in browser) disconnects and reconnects due to bad network will the login call be made again? In that case a new sessionID will be generated which is undesirable.
deepstream will internally cache the authentication data and re-send them upon reconnecting. However, if establishing a connection fails continuously and the connection closes with an error state you'd have to call .login() again manually.
Related
Using JS SingleR client v7.0. Server side is ASP.NET Core V5.0.
When inspecting the server side I get the same cookie value from client for every hub method call equal to that of the cookie value received during the initial connection. This is true even though the cookie value on client has been updated and changed in the time between the connection creation and subsequent method calls to the hub.
If I reestablish the connection, the new cookie does get sent but then again it becomes stale as it is never updated on subsequent hub method calls.
From what I understand WebSockets should send the client cookie every time through it's header but seems to keep providing the old cookie. Is there some setting in SignalR that does some caching on the cookie per connection?
This is by design. The websocket connection is a single request, the connection cannot be updated per invocation because it's not an HTTP request.
I am building a single page react app that uses redux as state manager and an express node js as backend server, but I don't know what is the best way to authorize my users in the application!
If it was a php or express-js website, I could use PHPSESSION or express-session to manage users sessions data but now the single page web application is separated from the backend and I can't manage sessions like before!
My idea is to make a session id for each new web request, then save it for client in local storage, then in the server store all needed informations in a database and when application have an API call, send that id in request header. Then we can check authorizations by using that implemented session.
But I thought if there was a simpler way to handle this problem that has no need to make a session implementation by myself.
(I don't want to use third party services like firebase or okta or save all session data in client part like JWT.)
At the end i implemented a custom session manager ( SessionMush ) so the client send a request to server and get a token id then use it to access its session in server.
Each session should be accessible by an identification token ( here knows as sid ) so the application can save that token to access and use that session. A server side state for your application can be use for saving clients auth state or any temporarily data about clients that you want to use them on server side so in your application you will save that identification token and then with each request you will send it in http headers then the server will know who you are and what was you did before on the application based on that saved session data in database (server side state for that id) so it can serve the needed information for you based on the client identity and it's state on the server. It created to be used as a express middleware and mongodb as data store.
When your application have no session and it loaded for the first time it sends a request to the server to gain an identity for itself When the request received to the server, server analyze the request and it'll find out that there is not exist any session id (sid) so it will make a new one for this request and add it to response header part so when the server decide to send the response it will send that created session informations too. The client should save that informations to use that session for its other requests. it can send that id in the request header part to show its identification. A session can be expire too when it doesn't used for a threshold time. so when the server get wrong or expired session it will behave to it like a request without any session so it will create a session for that request and send its informations like what we explained before.
Do we need to call WL.Client.Login API before submitLoginForm in MobileFIrst 7.1.0 while using Formbasedauthentication (LoginModule = LDAP).
IBM documentation does not mention it but we found that if we do not call it MobileFirst Server does not send any Challenge.But we call that before submitLoginForm we receive all challenge handler and got authenticated from LDAP.
Please Advice.
Yes.
submitLoginForm() is the step where the client side code ( challengehandler) sends the credentials to the server. This is in case of Form based login.
The challenge will come from the server as a result of the application connecting to the server by:
WL.Client.connect(). In this case, if the application is protected, server throws the challenge.
WL.Client.login(realmName). If this is a custom realm, the server sends a challenge to be handled.
Invoking a protected resource using WLResourceRequest. The server responds with a challenge.
When user enters wrong credentials to an earlier challenge
When the challenge comes, you handle it in the challengehandler. The handleChallenge flow in the client ends with the client submitting the credentials in the login form and sending it to the server using the API - submitLoginForm().
Using WIF, WCF within a Silverlight client accessing backend WCF services.
The application sign out uses Federation Authentication Module SignOut method which in turn calls Session Authentication Module (SAM) DeleteSessionTokenCookie for the local RP (Relying Party) sign out. A sign out to the the IP (Issuing Party) is subsequently called. All of this functions as expected.
I have come across the following multiple browser scenario relating to shared session that results in a “remote server returned an error not found” issue. If IE's "New Session" is used this is not an issue.
Steps:
Use IE shortcut to open a browser instance 1, navigate to application and login.
Use IE shortcut to open a browser instance 2, navigate to application and login.
Log out of application in browser instance 2.
Perform any operation that requires communication to the server. e.g. Log out of application browser instance 1.
Result: “remote server returned an error not found” exception
Is it possible to detect that the WIF token has been deleted prior to making a WCF call in browser instance 1 and so notify the user. The IdentityModelServiceAuthorizationManager.CheckAccessCore (OperationContext) method is being used to verify service access (authorization) prior to making any WCF service calls. Would it be possible to access and evaluate session token related information at this time? Or is there another approach that can be used?
I have a .NET client application that needs to communicate with a server using two distinct user credentials.
Lets say that the application runs two threads. When start running, every thread sends the user & password to authenticate and the server in return stores a cookie on the http session. The subsequent calls send the authentication cookie and not the user credentials.
We have two cookies for the same process. How does wininet "knows" to send the appropriate cookie for each thread?
Does wininet manage the cookies collection per thread? per http session? per process?
Thanks
Wininet uses cookies per process.
However in a .NET client you can use a Cookie container with the HttpWebRequest object.
You create one cookie container for each "session". Assign the appropriate container to each HttpWebRequest when making the various requests for each session.