Answered by:
C based XMPP libraries for developing MSN Chat client
-
Hello,
I am trying to develop a C based MSN chat client.
i want to know weather there are any C based XMPP libraries, that i can use.
- Changed type Deepak Duggal Tuesday, June 26, 2012 8:40 AM
Tuesday, June 26, 2012 8:40 AM
Question
Answers
-
There are two main ways for the OAuth process to work. This is described fully here: http://msdn.microsoft.com/en-us/library/live/hh243647.aspx
The first is that your users are interacting with a website which is hosting your service. In that case, the redirect URL would be a URL pointing at your service, which would receive an authentication code. You can then use that auth code between your server and the Windows Live service to fetch an access token.
The second is that for client developers, for mobile phone apps and the like, you can embed a browser control as part of the app. For Windows Phone apps, this might be a WebBrowser control. For Android, a WebView. I don't know the specifics of your platform. However, the app should be notified when a URL is loaded into that embedded browser. The redirect URL you would use in this second case is "https://login.live.com/oauth20_desktop.srf".
You'll find this mentioned on the OAuth 2.0 page under "Authorization code grant flow", item 8. Even if you aren't requesting an authorization code specifically, the special desktop URL is still usable.
Example: my client app will open a browser with this address: https://login.live.com/oauth20_authorize.srf?response_type=token&scope=wl.messenger&redirect_uri=https%3A%2F%2Flogin.live.com%2Foauth20_desktop.srf&client_id=(your client ID here)
You would supply your own client ID, generated by visiting https://manage.dev.live.com/
After giving my password and consenting to let the app log me in, I am redirected here by the Windows Live login page: https://login.live.com/oauth20_desktop.srf?lc=1033#access_token=(my token here)&token_type=bearer&expires_in=3600&scope=wl.messenger%20wl.offline_access
Your client should listen to changes in the URL of the embedded browser, and know when it has loaded something at https://login.live.com/oauth20_desktop.srf. When that happens, you know that you have an access token. You can then extract the access token from the full URL.
I hope that is useful to you.
Thanks,
Bill
- Edited by Bill Garrett Wednesday, June 27, 2012 11:24 AM Slight rewording of option two to be clearer
- Proposed as answer by brew window Friday, June 29, 2012 4:48 AM
- Marked as answer by Deepak Duggal Tuesday, July 10, 2012 5:22 AM
Wednesday, June 27, 2012 11:02 AM
All replies
-
I'm using wocky: http://cgit.freedesktop.org/wocky, it is open-source and uses GLib.
Tuesday, June 26, 2012 9:56 PM -
thanks for the reply...
i have also tried another library "libstrophe", but for MSN messenger , i am facing some problems..
1) Shall i use the REST - as my platform is C based.?
2) Do i need to open the browser for Login in MSN , if i use REST?
3) can u please describe a basic flow of making request form Client to MSN , using XMPP. can u explain the use of SSl and SASL in this flow??
Thanks for ur help again,, i am kinda new in XMPP and Mobile chat app area... :)
Wednesday, June 27, 2012 5:14 AM -
Hi Deepak,
You can find a list of XMPP libraries, including some in C, here: http://xmpp.org/xmpp-software/libraries/
Other users can hopefully share their own experiences with specific libraries, or (like Xavier), suggest others to try.
To log in, your client must present an OAuth 2.0 access token. This is only obtained by directing the user to an external browser, or to a browser embedded in your app.
The general flow of requests:
1. A client opens a socket to the server.
2. The server and client exchange stream stanzas. The server advertises TLS and SASL stream features.
3. The client negotiates TLS with the server, creating a secure channel. NOTE: you may receive a see-other-host stream error once this is done. This is normal, it means you should reconnect to the server whose host name came with the error.
4. The client sends a SASL stanza containing the OAuth 2.0 access token obtained from the browser, earlier.
5. The server advertises Bind and Session stream features.
6. The client sends a bind stanza, then waits for the response.
7. The client sends a session stanza, then waits for the response.
8. At this point, the client is ready and can send presence, IMs, or other requests.
Hopefully this has been helpful. If you need more detail, I can also post logs of a real session (with details like access token removed).
Thanks,
Bill
- Proposed as answer by JOshiroModerator Wednesday, June 27, 2012 5:51 PM
Wednesday, June 27, 2012 6:18 AM -
Hi Bill,
I read so many threads for same question but well explained by you .
Just need one more information . Since now we need to open browser for login , I need to understand format of request for it (not worked in such scenarios) .
* what is redirect url in the request . why it is needed and do this require dedicated server kind of stuff .
Thanks.
Wednesday, June 27, 2012 9:53 AM -
There are two main ways for the OAuth process to work. This is described fully here: http://msdn.microsoft.com/en-us/library/live/hh243647.aspx
The first is that your users are interacting with a website which is hosting your service. In that case, the redirect URL would be a URL pointing at your service, which would receive an authentication code. You can then use that auth code between your server and the Windows Live service to fetch an access token.
The second is that for client developers, for mobile phone apps and the like, you can embed a browser control as part of the app. For Windows Phone apps, this might be a WebBrowser control. For Android, a WebView. I don't know the specifics of your platform. However, the app should be notified when a URL is loaded into that embedded browser. The redirect URL you would use in this second case is "https://login.live.com/oauth20_desktop.srf".
You'll find this mentioned on the OAuth 2.0 page under "Authorization code grant flow", item 8. Even if you aren't requesting an authorization code specifically, the special desktop URL is still usable.
Example: my client app will open a browser with this address: https://login.live.com/oauth20_authorize.srf?response_type=token&scope=wl.messenger&redirect_uri=https%3A%2F%2Flogin.live.com%2Foauth20_desktop.srf&client_id=(your client ID here)
You would supply your own client ID, generated by visiting https://manage.dev.live.com/
After giving my password and consenting to let the app log me in, I am redirected here by the Windows Live login page: https://login.live.com/oauth20_desktop.srf?lc=1033#access_token=(my token here)&token_type=bearer&expires_in=3600&scope=wl.messenger%20wl.offline_access
Your client should listen to changes in the URL of the embedded browser, and know when it has loaded something at https://login.live.com/oauth20_desktop.srf. When that happens, you know that you have an access token. You can then extract the access token from the full URL.
I hope that is useful to you.
Thanks,
Bill
- Edited by Bill Garrett Wednesday, June 27, 2012 11:24 AM Slight rewording of option two to be clearer
- Proposed as answer by brew window Friday, June 29, 2012 4:48 AM
- Marked as answer by Deepak Duggal Tuesday, July 10, 2012 5:22 AM
Wednesday, June 27, 2012 11:02 AM -
Thanks will check details n update :)Wednesday, June 27, 2012 11:23 AM