Using several clients in threads and authorisation

VojkoCendak · 2012-11-17 01:49:54

Hi,

How can we use TSQLite3HttpClientWinSock clients in several threads?
- we login in main thread. How can we "transfer authorisation" from main thread client to clients in threads, which poll in background?
In RO there is neat way to make each client same with GUID. we just copied same GUID to threads and that's it.

ab · 2012-11-17 11:38:39

Won't it break the sicClientDriven mode?

Is it really necessary to share the same exact session on multiple threads at the client side?
Is it not enough to create a per-thread session, with the same user name?

Client-Server authentication in mORMot was designed to be very secure, using a "challenge" pattern, with integrated token time out, and strong mathematical encryption of the password.
It tries to avoid most used attacks, like man-in-the-middle, replay, zombi sessions or brute force.
I think RO does not have such features, so can re-use an existing GUID - so IMHO it is a security issue, not a feature.
What you ask may impact deep changes and a more complex implementation on the client side, therefore adding additional security leaks, with no real benefit IMHO.

VojkoCendak · 2012-11-19 12:47:56

Is it really necessary to share the same exact session on multiple threads at the client side?

We use at least several threads to perform background tasks, which
need "same session data" serverside to control access to.
This could be ok, but we want to see how many users are in our case it would be at least 2 same logged users,
one normal and others in thread.

Is there a way to pass some addon data and attach it to session on login ?
Maybe then we could manage to group several connections to one group of sessions?

Client-Server authentication in mORMot was designed to be very secure, using a "challenge" pattern, with integrated token time out, and strong mathematical encryption of the password.
It tries to avoid most used attacks, like man-in-the-middle, replay, zombi sessions or brute force.
I think RO does not have such features, so can re-use an existing GUID - so IMHO it is a security issue, not a feature.

What about security editing would be more flexible, if the developer wants to?
Because if developer makes addon service methods to access Tauth tables, then
security is breached anyway.

Last edited by VojkoCendak (2012-11-19 22:38:18)

ab · 2012-11-20 10:51:09

VojkoCendak wrote:

What about security editing would be more flexible, if the developer wants to?
Because if developer makes addon service methods to access Tauth tables, then
security is breached anyway.

It was security at the URL RESTful level, not about the server-side itself.

VojkoCendak · 2012-11-20 17:14:20

It was security at the URL RESTful level, not about the server-side itself.

ok. I undestrand. Thank you.

2. So in current implementation there is no way to have common session, right?

Is there any way I could manage several sessions serverside:
like my own ID for application which has several SetUser('',''), but knows they belong to same group ?

ab · 2012-11-20 20:03:34

You can easily use your application-level session, then use it on server side using it as parameter to your services.

Or you can use the user id to identify the session.

VojkoCendak · 2012-12-01 08:11:30

You can easily use your application-level session, then use it on server side using it as parameter to your services.

we already did that, our auth on client and that's it.
But we miss serverside statistics, eg. how many clients, which clients, ...

Or you can use the user id to identify the session.

I still don't understand how can we use this serverside?

I'm new to morm, so any code helpers would be nice.

mORMot Open Source

#1 2012-11-17 01:49:54

Using several clients in threads and authorisation

#2 2012-11-17 11:38:39

Re: Using several clients in threads and authorisation

#3 2012-11-19 12:47:56

Re: Using several clients in threads and authorisation

#4 2012-11-20 10:51:09

Re: Using several clients in threads and authorisation

#5 2012-11-20 17:14:20

Re: Using several clients in threads and authorisation

#6 2012-11-20 20:03:34

Re: Using several clients in threads and authorisation

#7 2012-12-01 08:11:30

Re: Using several clients in threads and authorisation

Board footer