This forum has been archived. Please start a new discussion on GitHub.

Client/Server authentication after Login

i am new to ICE and network programming. I have been thinking about a sufficient way to authenticate client request at server side, after a login process. Do i have to send the username/password for each remote method call, or is there a built in method for client authentification in ICE, like a sessionId?
I have another general question. If i use the following slice code (only an example):
class Person {
	string getName();

interface Server {
	void logIn(Person user);
Is there a way to prevent, that a malicious client application passes a subclass of Person, that contains malicious code in the getName() method? In other words: is there a way to ensure, that the passed object is a specific implementation?

thanks, stefanjp


  • I have found an answer to my first question (and much more useful information) in the Chat Demo. However i can't find an answer to my second question. Let me clarify my concern:

    1. Everyone may connect to my server.
    2. My server has to call methods of objects, which were instantiated by his clients.
    (3. Client and Server are written in C++)

    Question: Can I check, if the clients are using objects generated by class definitions distributed by myself?

    I have been thinking of 2 possible solutions:
    1. Develope a Communication-Protocol + use only basic fundamental data type parameter for remote method calls. Disadvantage: huge maintenance effort, as i will have to expand the protocol constantly.
    2. Generating a checksum of an "original" object and compare it with the checksum of the objects received by my clients. I guess that won't work.

    I have found recommandations on the web, which don't work for me, of are just :eek:
    1) Remote Objects should not be exposed to the World Wide Web. Expose Remote Objects if the server is accessible from trusted sources only
    2) Similarly, Do not use TCPChannel for servers exposed to the internet as this does not have built in authentication mechanisms
    3) Use SSL and IIS AUTHENTICATION features of IIS and ASP.NET

    Maybe i am a bit paranoid :), but a risk is a risk.

    Thanks in advance,
    cheers stefanjp