Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

session management question #66

Open
mvayngrib opened this issue May 17, 2015 · 6 comments
Open

session management question #66

mvayngrib opened this issue May 17, 2015 · 6 comments

Comments

@mvayngrib
Copy link
Contributor

is there a way to manage sessions? I have the following scenario:

User A and User B are talking
User B falls off a cliff
User B gets back online, but has different instance tags so User A ignores him.

One way of solving this:

User A's OTR instance can notify it about query messages, e.g. via an event 'query'. Then User A can create a new OTR instance to respond to that new connection

Do you know of a better way?

EDIT: skimmed over OTR spec...it's long :) Here's another option I see, though I'm not sure I see confirmation in the spec:

When receiving a "query" message, if you already know the other party's instance tags, then in addition to re-initializing AKE, like the code already does, reset this.their_instance_tag. Otherwise continuing with AKE has no chance of succeeding.

EDIT: oof, another obvious solution is having persistent instance tags. But if for the sake of argument you don't use persistent instance tags?

@arlolra
Copy link
Owner

arlolra commented May 30, 2015

Sorry for being slow here. I'll take a look shortly.

@arlolra
Copy link
Owner

arlolra commented May 30, 2015

Right, so we don't really have a great story for session management, but that can be improved.

Your edits above took you to the right places. Ideally, a client has a persistent instance tag. At present we're complying with the spec, but only because it's kind of vague in this area.

Looking at libotr, https://github.com/off-the-record/libotr/blob/master/src/message.c#L996-L1004

/* Get the context for this instance */
if (their_instance >= OTRL_MIN_VALID_INSTAG) {
  context = otrl_context_find(us, sender, accountname,
    protocol, their_instance, 1, &context_added,
    add_appdata, data);
} else {
  message_malformed(ops, opdata, context);
  return 1;
}

The 1 in the arguments to otrl_context_find meaning create one if it isn't found.

When receiving a "query" message, if you already know the other party's instance tags, then in addition to re-initializing AKE, like the code already does, reset this.their_instance_tag. Otherwise continuing with AKE has no chance of succeeding.

Unfortunately, that defeats the whole purpose of instance tags.

User A's OTR instance can notify it about query messages, e.g. via an event 'query'. Then User A can create a new OTR instance to respond to that new connection

That puts the burden of session management on client libraries, which doesn't sound great. Then they'll have to parse messages to decided which session they belong.

I think we need to refactor a bit of code.

@mvayngrib
Copy link
Contributor Author

@arlolra thanks for getting back to me. I understand...sort of :) Is this something you guys plan on developing in the near future?

@arlolra
Copy link
Owner

arlolra commented May 30, 2015

Unfortunately, it's hard to give a timeline. It's just me maintaining this voluntarily. But I'll probably peck away at it in my spare time over the upcoming weeks. Patches welcome :)

To solve your problem immediately though, you can always set ALLOW_V3 = false.

@mvayngrib
Copy link
Contributor Author

cool, looking forward to it, and thanks for the tip! If you need someone to bounce approaches off of, I'll try to make myself available.

@arlolra
Copy link
Owner

arlolra commented May 30, 2015

Thanks for the offer and raising the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants