Hey JeffP,
@Gus, I'm not well-versed with authentication protocols. What I gleaned from the developer/Network tab of the browser (as suggested by zamronypj), upon login the Request sent contains the username and password in plain text, plus a CSRF token of random characters (generated by the login form).
DRATS!!! I always forget to mention the developer tools on the browser. Thanks @zamronypj for suggesting that. Quite easier than messing with Fiddler and/or WireShark
So, from what you're telling me here, nothing more than a regular POST to a login endpoint. Kewl!!
And then there is a request cookie and a response cookie. Sorry, just an excited noob here.
You'll have to jot all that down in order to mimic the exact same behaviour.
fphttpclient will allow you to mimic that with a bit of effort.
So from my point of view, here's a crude action list of how to do it:
- Perform a GET to the login endpoint in order to get the HTML of the form
- Save any cookie that this GET returns
- Perform a REGEX search for the CSRF token
- Perform a POST to the login endpoint with the 3 elements(login, Password, CSRF Token) and any cookie that point 2 has
- Save any cookie that this POST returns and add it to the list that started on point 2
- Perform GET or POST actions to the API endpoints with the cookies provided
Like I said, this is very crude and will give you a set of steps to look at and then try to implement.
NOW.... May I suggest something else?
This is not how any OR most APIs validate a user.
Usually it involves a secret token like a Client API Key so you don't have to mess with REGEX and stuff...
I would advise dropping this way of doing things and maybe try to get your server to have the Client Key approach?
Just my 2cents
I think after solving out the login issue, I can get the rest sorted out with fphttpclient.
I concur with you on this.
Cheers,
Gus