Why is a login process not embedded in RVMediaServer?

DeerBear · Post by **DeerBear** » Thu Mar 17, 2016 3:26 pm

Hello!

It wouldn't really require lots of code to do for the author.

All he needs to add is:

* A "RequiresLogin" property
* A "OnLoginAttempt" event
* A "OnCreateUser" event

The code behind these can be taken straight from the samples and integrated.

A[/list]

Post by **Sergey Tkachenko** » Thu Mar 17, 2016 3:53 pm

Information about user accounts needs to be stored somewhere, even when the server is not running.
Currently, we prefer not to embed database functionality in the server components.
You can implement a login process yourself, see the demos in Demos\ClientServer\Login

PS: in the next version of RVMedia, a password protection will be added to groups (i.e. chat rooms) in the server/

DeerBear · Post by **DeerBear** » Thu Mar 17, 2016 4:35 pm

Nah, you simply need to provide a login attempt event such as this:

Type
TMVLoginAttemptEvent = procedure( Sender: TRVServer; UserName, Password: String;var AllowLogin: Boolean );

This is all that is needed for a start.

Another option, which would be cooler but much more code-intensive, would be to encrypt the credentials before they're sent. If you want I can give that a spin and let you have a tentative implementation.

A

Post by **Sergey Tkachenko** » Thu Mar 17, 2016 6:17 pm

Adding the event is not a problem.
A problem is in limiting activity of unlogged clients.

DeerBear · Post by **DeerBear** » Thu Mar 17, 2016 7:03 pm

I wouldn't have thought so.
If login is refused, a GUID won't be set, and if the client requires login, that is necessary. Also, there won't be any session, so that could be used on the server.

Post by **Sergey Tkachenko** » Fri Mar 18, 2016 8:43 am

GUID is not assigned by the server, it is generated on the client, and client includes its id in each sent data packet.
There are many problems to implement a full-functional authorization. For example, UDP server does not have a permanent connection. In TCP server, several connections are established, and some of them can be automatically reconnected if broken, so sometimes re-authorization may be necessary.

I understand that this is an important feature, but currently we have more high-priority tasks to complete, sorry. When it will be implemented, it will be implemented in a good way, implementing a quick-and-dirty solution is a waste of time, I believe.

DeerBear · Post by **DeerBear** » Fri Mar 18, 2016 9:10 am

Can you give me an approximate time-frame?

Something like "Fall" or "Next year" will do, I just need to have a rough timing.

A

Post by **Sergey Tkachenko** » Fri Mar 18, 2016 12:58 pm

Sorry, I cannot. Currently, we a porting RVMedia for FireMonkey.
When we complete it, we can think about authorization. Although, there are more interesting features to implement, such as ONVIF support

DeerBear · Post by **DeerBear** » Fri Mar 18, 2016 1:49 pm

Interesting and important are two entirely different things.
Authorization is important, very important.

So important, in fact, that I will be obliged to evaluate other SDKs before I have even written a line using yours, because - come on - your priorities are clearly misplaced.

Please give me a knock when you come back to your senses.

Thanks.