New Posts New Posts RSS Feed: SignalR
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

SignalR
 Post Reply Post Reply Page  12>
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
kdev View Drop Down
Groupie
Groupie
Avatar

Joined: 03-Jan-2013
Posts: 83 		Post Options Post Options   Quote kdev Quote  Post ReplyReply Direct Link To This Post Topic: SignalR
    Posted: 06-May-2013 at 5:28am
Hi,

I want to use SignalR in order to notify client users from the server and wanted to know if someone has succeded in getting a server side EntityManager connected with the same login credentials as it would be if it was called through an RPC call.

In my case, I have customized the login process in order to use my own authentication logic rather than asp.net login process I've followed that, and didn't find how I can create, when I use SignalR Invoke method, a correctly authenticated EntityManager. I need to have that EntityManager using the same credentials as it would have if it was called in a DevForce RPC method call.

I would be very interesting if you could give some advise on how to inegrate SignalR with DevForce.

Regards,
Back to Top
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786 		Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post Posted: 09-May-2013 at 10:39am
kdev,

If you pass the sessionKey, you will be able to authenticate the server EM:

on the client: 

      var sessionKey = Authenticator.Instance.DefaultAuthenticationContext.SessionKey;

      myIHubProxy.Invoke("MyPubSubService", sessionKey).Wait();


on the server: 

public void MyPubSubService(Guid sessionKey) {

  var em = new EntityManager();

  Authenticator.Instance.Login(sessionKey);

  // do something

}
Back to Top
kdev View Drop Down
Groupie
Groupie
Avatar

Joined: 03-Jan-2013
Posts: 83 		Post Options Post Options   Quote kdev Quote  Post ReplyReply Direct Link To This Post Posted: 09-May-2013 at 2:20pm
Thank you Silvio,

On the client side I had to oper a little differently since I'm using Cocktail : 
var authenticationService = Composition.GetInstance<IAuthenticationService>();

var sessionKey = authenticationService.AuthenticationContext.SessionKey;

and then pass sessionKey through the Invoke.

But on the server side the EntityManager try to login with no credentials (= null)

Please note that I have implemented a custom IEntityLoginManager...

Regards.

Edited by kdev - 09-May-2013 at 2:21pm
Back to Top
kdev View Drop Down
Groupie
Groupie
Avatar

Joined: 03-Jan-2013
Posts: 83 		Post Options Post Options   Quote kdev Quote  Post ReplyReply Direct Link To This Post Posted: 09-May-2013 at 3:04pm
By adding the following code to my LoginManager, it worked, but I'm not very happy with this workaround...
Is there any other better solution that avoids the call of my custom Login() method ??? 

public class LoginManager : IEntityLoginManager

{

     public virtual IPrincipal Login(ILoginCredential credential, EntityManager entityManager)

     {

          if (entityManager.IsLoggedIn && entityManager.AuthenticationContext.Principal is IMyOwnPrincipal)

                return entityManager.AuthenticationContext.Principal;

...


Edited by kdev - 11-May-2013 at 6:52am
Back to Top
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786 		Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post Posted: 13-May-2013 at 10:42am
kdev,

Unlike Push in DevForce 2010, the SignalR request is not a DevForce request and a principal is not automatically passed nor an authenticated EM will exist.
Because of that, you will need to pass that information explicitly and manually login so to authenticate your EM.
I find the most secure way to do this by passing the sessionKey. This way you are not at risk of sending sensitive information across the wire. You will still have to login though.
Note that in my test, I used the default ASP.NET authentication and it worked fine. Since you are using a custom Login Manager, you should adapt your customization for such. (i.e. as you have done in your post above)
Back to Top
kdev View Drop Down
Groupie
Groupie
Avatar

Joined: 03-Jan-2013
Posts: 83 		Post Options Post Options   Quote kdev Quote  Post ReplyReply Direct Link To This Post Posted: 05-Jul-2013 at 10:54am
Hi,

I come back to you about my problem, after some tests I found an issue with your proposition.

The first time Authenticator.Instance.Login is called on the server it generates a specific sessionkey and store it along the CURRENT Principal in the property DefaultAuthenticationContext.
Then every time I start a new work on the server the Authenticator has these informations, even though another user did it.
It results that, if I check the Principal on the newly created entityManger, the Identity.Name might not have MY name but the name of the first person who did "initialize" the Authenticator.Instance.DefaultAuthenticator.

Should we use the Authenticator singleton when working on a server ?

I tried to Logout the DefaultAuthenticationContext just before to Logging it again, but it did raise and exception ("Implicit login is not allowed when the AuthenticationContext is logged out")

But once I save my changes, the EntityServerInterceptor get an EntityManager with the correct Principal.

What should I do to have the correct Principal in the manager I created ?
Back to Top
kdev View Drop Down
Groupie
Groupie
Avatar

Joined: 03-Jan-2013
Posts: 83 		Post Options Post Options   Quote kdev Quote  Post ReplyReply Direct Link To This Post Posted: 12-Jul-2013 at 5:57am
Any info about this issue ?
Back to Top
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786 		Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post Posted: 12-Jul-2013 at 9:22am
kdev,

Sorry for the delay.
I'm checking this issue and will follow up soon.
Back to Top
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786 		Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post Posted: 15-Jul-2013 at 2:41pm
kdev,

I was partially able to reproduce the scenario you described.
While I see that the server holds the information of the user who made the first call, I don't get any exception while trying to logout/login on the second call.

Since you are using the DefaultAuthenticationContext, "remembering" the login information is actually expected.
If you don't want to keep the login information, you might want use an EM's specific AuthenticationContext instead: 


var em = new EntityManager();

em.AuthenticationContext = Authenticator.Instance.Login(sessionKey);
Back to Top
kdev View Drop Down
Groupie
Groupie
Avatar

Joined: 03-Jan-2013
Posts: 83 		Post Options Post Options   Quote kdev Quote  Post ReplyReply Direct Link To This Post Posted: 02-Aug-2013 at 8:42am
Hello,

I come back with a side effect, and I think there is a bug in DF but I'm not sure...

After using successfully the sessionKey obtained by this method :
Composition.GetInstance<IAuthenticationService>().AuthenticationContext.SessionKey

I leave my (SL) application launched without activity for a while.

After that I successfully query some entities (I think that the client EM reconnects after a timeout)

But when I try to use a new EM on the server with the session key authenticationService.AuthenticationContext.SessionKey I have an exeption saying : SessionKey was not found. You must re-login.

Can you reproduce the issue ?

Regards.
Back to Top
kdev View Drop Down
Groupie
Groupie
Avatar

Joined: 03-Jan-2013
Posts: 83 		Post Options Post Options   Quote kdev Quote  Post ReplyReply Direct Link To This Post Posted: 12-Aug-2013 at 5:47am
Any news ?
Back to Top
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786 		Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post Posted: 12-Aug-2013 at 9:34pm
kdev,

I was not able to reproduce the problem. 
Can you provide a small solution showing the issue?
Back to Top
kdev View Drop Down
Groupie
Groupie
Avatar

Joined: 03-Jan-2013
Posts: 83 		Post Options Post Options   Quote kdev Quote  Post ReplyReply Direct Link To This Post Posted: 24-Oct-2013 at 3:52am
Hi Silvio,

Here is a test project which reproduce the sessionKey issue with SignalR 2.0 and Cocktail.

TestSignalRSessionKey.zip

I have set the userSessionTimeout to 2 min.
If you click on the button right after starting the application, no exception will be thrown in the hub. But if you wait 2 or more minutes to click on it, it will raise an exception « SessionKey not found – you must re login » (put a break point on the hub to catch the exact message because the error is not handled on Silverlight).

Do you think the fix could be made for the next release of DF ?

Regards




Edited by kdev - 24-Oct-2013 at 3:52am
Back to Top
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786 		Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post Posted: 24-Oct-2013 at 12:41pm
Thanks, kdev.

We will look into your sample and determine what the issue is.
Back to Top
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786 		Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post Posted: 29-Oct-2013 at 5:15pm
kdev,

It turns out that this is not a bug.
If after the session timeout the client performs a query or save, it will still work because DevForce silently logs the client back in because the “session bundle” contains enough information to do the login. 
You shouldn't expect it to happen on a SignalR call.

In this situation you can either log back in or perform an operation that would trigger the silent login.
Back to Top
kdev View Drop Down
Groupie
Groupie
Avatar

Joined: 03-Jan-2013
Posts: 83 		Post Options Post Options   Quote kdev Quote  Post ReplyReply Direct Link To This Post Posted: 30-Oct-2013 at 4:42am
Hi,

Executing a query before a SignalR call indeed reconnects the client's EntityManager but doesn't fix the signalr issue as the SessionKey provided by the AuthtenticationContext never changes.

However, if the "query trick" worked, I find it very annoying to have to do a dummy query before every signalr call. I currently have many signalr calls and plan to have a lot more.

Below the updated project using a query prior to the signalr call

You said "you can log back in",  how would you do that and based on which event/information ?
Currently I have no way to know if the client is disconnected, the information on the AuthenticationContext always show "LoggedIn".



Regards
Back to Top
 Post Reply Post Reply Page  12>

Forum Jump Forum Permissions View Drop Down