In the
previous part, I talked about restoring the function of updating quotes.
The next function that I wanted to restore is synchronization.
data with the server.
For this, it was necessary to solve two problems: linking the file to the account with subsequent authentication and the actual synchronization itself.
')
And since this topic is very extensive, here I will talk about solving the first part of the problem.
At that time, the MSN portal was already the center of access to Microsoft online services, so it’s quite natural that Money required an account of this portal.
After linking the file to the account, functions for synchronizing data between devices, viewing transaction records online, and even receiving invoices became available.
For user authentication in Money, the Passport service was used, and in particular its xml protocol.
The whole authentication procedure worked as follows.
1. At the URL specified in the
MnyPassClientXML parameter of the mnypass.ini Money file, it requests an xml file (client.xml) listing the links for accessing the Passport service using various protocols. The file contains sets of links grouped by domain.
2. In accordance with the value of the
MnyPassDefaultDomain parameter from mnypass.ini, a domain entry is selected in the resulting file. In this entry, the element contains the URL for which the HTTP POST request is generated as follows:
<?xml version="1.0"?> <LoginRequest> <ClientInfo name="mnypassport" version="1.35"/> <User> <SignInName>user@mail.com</SignInName> <Password>123456</Password> <SavePassword>false</SavePassword> </User> </LoginRequest>
The meaning of the elements is completely understandable without explanation.
From the server, either a successful authorization message should come back:
<LoginResponse Success="true"> <Redirect>https://moneycentral.msn.com/home.asp?did=1&t=AqHf*J!puuvpcU01kK*PA9&id=229</Redirect> </LoginResponse>
Redirect is an optional field. If available, Money makes a GET request to the specified URL, but the result is not displayed anywhere.
Or an error message:
<LoginResponse Success="false"><Error Code="e5b"/></LoginResponse>
where
Code is one of the values: e8a, e15, e14, e13, e12, e11, e10, e9, e4, e3, e2, e1, e8, e5b, e5a.
Error decoding is in the file passport.htm
HTTP response statuses are also taken into account when processing.
When receiving a positive response, the user is considered authorized, and Money proceeds to the next step.
3. From the misurls.xml file, take the values of the two parameters
PASSPORTURL and
UPSURL .
PASSPORTURL is used to form a GET request, the results of which are not involved anywhere else.
But the URL from
UPSURL is used to form a POST request of the following form:
<MnyOpts><CryptSeed/><GUID/><UserGuid/></MnyOpts>
Empty values of elements mean that Money wants to receive their values from the server.
The first two are simple:
GUID - the identifier of the main Money file associated with the account.
UserGuid - user ID on the server.
But
CryptSeed is supposedly used to weaken the encryption key. I can’t say for sure, because I did not track the use of this parameter, but not explicitly used.
The expected server response is quite obvious:
<MnyOptResponse> <CryptSeed>1234</CryptSeed> <GUID>56159e04-fce1-4dbc-9e8e-9ca310dc69db</GUID> <UserGuid>9e79710b-ca04-4b6a-b299-38bf3c33366c</UserGuid> </MnyOptResponse>
The value of the
GUID parameter may be empty if the file is not yet associated with the account. Then, and even if the value of this parameter does not match the file identifier, Money will send another request of the form
<MnyOpts> <GUID>56159e04-fce1-4dbc-9e8e-9ca310dc69db</GUID> </MnyOpts>
to bind the file.
The server response must contain the same identifier.
After successful completion of all actions, the user is considered authorized and given access to the program's functions.