My problem is: client access to a server 1. Client authentification on that server is based on a form containing username and password fields using POST method and https. 2. I have no access to that server but a valid data pair username-password. I want to give access to my clients on that server using my account authentification data, but I don't want to let them see those data in browser's address bar or in the source page... So if anyone has idea about it please let me know. Thanks in advance!
For thise coming in late, we started this conversation in this thread and it appears we're starting again. Lets name the players: The secured site is called 'secured' or secured.com To get in, you have to post a username and password. Then the secured site will maintain a session so you don't have to log in again. You are called 'home' or home.com. You have the username and password for the site secured.com. The client is called 'client'. You want the client to be able to login to secured.com, but you would prefer they didn't get the username and password. First I have to ask: is this legal? It sounds dodgey. :roll: Going back to my first solution, the client sends a request to home.com asking it to give access to secured.com. home.com responds to client with an autosubmitting form:
You can see this causes the client to send a request to secured.com with the valid username and password. It is easy but not quite straight forward for the client to obtain the username and password values from this page. The second method goes like this: Client again sends a request to home.com asking for access to secured.com. Home.com opens a connection to secured.com and logs in with the username and password. secured.com gives home.com a cookie containing the sessionID. In its response, home.com writes the cross-domain cookie to the client and redirects the client to secured.com. When the client goes to secured.com, they are able to get in with the sessionID created by home.com. In theory the second mechanism may work, but I can think of several reasions it would fail. The advantage it has is that the username and password for secured.com are never seen by the client. Dave Oops, cut and paste of the code didn't work right... [ March 12, 2003: Message edited by: David O'Meara ]
Joined: Mar 09, 2003
Hi Dave! (again) Thank you for your support. I think I'll try the second solution. ...btw, our (edu) institution have free access for six months to that site.