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]
Why is a login process not embedded in RVMediaServer?
-
- Site Admin
- Posts: 17520
- Joined: Sat Aug 27, 2005 10:28 am
- Contact:
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/
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/
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
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
-
- Site Admin
- Posts: 17520
- Joined: Sat Aug 27, 2005 10:28 am
- Contact:
-
- Site Admin
- Posts: 17520
- Joined: Sat Aug 27, 2005 10:28 am
- Contact:
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.
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.
-
- Site Admin
- Posts: 17520
- Joined: Sat Aug 27, 2005 10:28 am
- Contact:
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.
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.