Using startSessionWithId with a sessionId passed in from elsewhere (e.g. JavaScript)

[Mark]

Hi, there,

I'll be receiving an AIM sessionId via external means which I'll then
be using with the wimas code to send IMs, etc. I see that I can use
startWithSessionId in the Session object, and pass along the AIM id.
But that method also requires a baseUrl and a User object. If I
understand things correctly, that baseUrl has to be a valid URL for a
fetchEvents call. I see that each fetchEvents call returns a new
baseUrl for each subsequent call, but how do I generate this first URL
to pass in to startWithSessionId when I'm passed in a sessionId from
an external source? Actually, from debugging, it's pretty easy to see
it's of the form:
http://<some ip>/aim/fetchEvents?aimsid=<sessionId>
where <sessionId> is the id I'm going to be passed. What about the
base ip? Can I use api.oscar.aol.com there?

More details might help. In fact, what's happening is this. We have
a bunch of server-side code my component does not have access to that
implements the clientLogin handshake and calls startSession. I have a
secure way of getting the sessionId from this server-side code. I
have no access to user passwords, so I can't do the clientLogin myself
(and there are a bunch of other reasons it doesn't make sense for me
to do it most of the time).

Thanks for any help,
Mark

[Rizwan Sattar]

Hi Mark,

It's funny you mention this because I've tried this exact approach myself. Unfortunately, you also *need* the baseUrl, replacing api.oscar.aol.com will not work. In addition, I found that it really helps to have at least the aimId of the session (i know you can probably extract it from the session id, but it's not guaranteed forever that the sessionid contains your aimid). This is so that your app (and wimas3) knows at least who you are (as it's not going to receive a "myinfo" event like a normal startSession).

The server that is providing you with the sessionid, can it also provide to you the baseURL? Wimas3 needs this because it needs to handle the fetchEvents loop. I don't think the WIM api likes to have 2 different things using the same session id (the fetch events loop), so I think it will kill the connection to the server-side one, though I'm not sure.

Thanks,
Rizwan

[Mark Rubin]

Hi, Rizwan,

Thanks for the quick response!

I suspected as much.  I'd have to check with my back-end teammate, but I'd be surprised if he couldn't hand me the baseUrl.  There's this small possibility of it's being stale, though, I suppose.  They do have timeouts, and I suppose by the time my request for this info (sessionId and baseUrl) comes back, we could be on to the next baseUrl.  But from the online web api docs, it seems that the worst that can happen with my using a previous fetchEvents URL is that some events are repeated to me, which is okay.  The docs also say to make sure to wait at least the timeToNextFetch seconds before issuing the next fetchEvents--so that's a bit tricky to coordinate, too.

You also answered my next set of questions: since someone else has issued my startSession for me, I wind up missing my myInfo event, as well as my buddyList event.  Hmm.  I guess there's no nice way to retrigger them.  Hmm.  This is starting to look a bit ugly--I guess I don't mind so much that my server has to repeat to me some stuff that AIM has already sent it, but I do worry about missing some event that could occur while I'm communicating with my server.

I didn't predict that using the same sessionId will kill the server-side connection, since I know AIM supports multiple points of presence; but I can see how it would only support that if we were using two distinct session Ids.

Thanks,
Mark

[Mark Rubin]

Ah, I just realized I was conflating a couple of things, and that I'm not entirely right here.  My team was considering two scenarios: one where the user might already be logged into AIM elsewhere on the site, and that I could reuse that session key; and one where our server-side code could just create a new session for me; in the first scenario, I would have missed the buddy list event as well as other events, and I'd have to worry about fetchEvents URL staleness.  But if our server-side code created a new session by simply calling startSession and did nothing else, and then left it to me to call fetchEvents for the first time, I could ensure that I get first listen to all the events.  Then, as Rizwan said, all I'd have missed was the myInfo information as well as the baseUrl for fetchEvents, and my server can hand me that. 

In a previous job, I was part of a team that wrote an IM client, and I was a bit stuck in an old IM API model (not one of these request/response style web models) where logging in itself just kicked off a bunch of events such as the buddy list from the messenger server.

Thanks again for all your help,
Mark