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

Sample for EventSource connection to Fastmail? #7

Closed
amyreese opened this issue Mar 7, 2021 · 11 comments
Closed

Sample for EventSource connection to Fastmail? #7

amyreese opened this issue Mar 7, 2021 · 11 comments

Comments

@amyreese
Copy link

amyreese commented Mar 7, 2021

Hey folks,

I'm working on a JMAP client for Python that uses AsyncIO, following the specs at https://jmap.io/spec-core.html. I've got the JMAP portion of the API functioning, and I can use that to fetch mailboxes and emails from my personal account. However, when trying to connect to the EventSource URL and stream changes, I always get a 401 Unauthorized error, with "Incorrect username or password."

I'm using the same HTTP client/auth parameters that I use for connections to the JMAP API, and the spec does not mention anything about authentication specific to the EventSource API. Is there a different authentication standard necessary for EventSource connections, or is this something that's not supported for third party applications with Fastmail?

@amyreese
Copy link
Author

amyreese commented Mar 7, 2021

Relevant code at https://github.com/jreese/jaymap/blob/main/jaymap/client.py#L107 if that helps.

@rjbs
Copy link
Member

rjbs commented Mar 9, 2021

Heya. Unfortunately, Fastmail's EventSource doesn't allow non-Fastmail clients to connect, yet. The story behind this is sort of tedious and stupid, boiling down to "updating the EventSource server for this kind of auth was a pain." Fortunately, our pain is coming to an end, and yours might be, too. Very soon we'll be deploying some overhauled code for our push notifications, and it should make fixing this much simpler.

I don't have a timeline, but getting this out the door is important to me. Not this week, but should be in the next few months.

@amyreese
Copy link
Author

Thank you for the response. So, just to be clear, the only option for receiving pushed changes in third party clients is to use the PushSubscription API with public URLs?

@neilj
Copy link
Member

neilj commented Apr 8, 2021

@jreese Unfortunately Fastmail hasn't implemented the PushSubscription part of the API yet either. This is also something we intend to do but haven't yet got to.

@karlnr
Copy link

karlnr commented Oct 28, 2021

Hi all,

I stumbled upon this issue after receiving the same invalid credentials response using the eventSourceUrl. Any updates or rough timelines available on the 3rd party Fastmail event or push apis?

EventSource-like refreshing of data is one of the last major pieces of a project I am working on, so I'd welcome and would be truly appreciative of any general pointers on the matter.

@1player
Copy link

1player commented Mar 22, 2022

Any update? I've just spent a few days writing a Fastmail/JMAP notifier for Linux, and I'm saddened to find out both the event source and the websocket methods of getting Push updates aren't available. I guess the project's on hold until non-Fastmail clients can access the event source.

@rjbs
Copy link
Member

rjbs commented Aug 9, 2022

Hey, as of today, you can create personal API tokens on beta.fastmail.com, which will work to get you an EventSource connection. PushSubscription support is on the road map, but the timeline isn't rock solid yet.

@rjbs
Copy link
Member

rjbs commented Oct 3, 2022

This hit production a few weeks ago, and so I'm closing this issue. I'm hoping for PushSubscriptions in early 2023.

@rjbs rjbs closed this as completed Oct 3, 2022
@rockorager
Copy link

rockorager commented Jan 30, 2023

Hey, sorry to bring up an old issue but I came across this today. I connected to the fastmail eventsource URL and was curious about the data received. It doesn't seem to follow the JMAP spec, and I was wondering if that is intentional?

There are two key differences:

Spec requires @type to be, well, "@type" and contain the string "StateChange". The event I received has the key "type" which appears to be a type of state change.

Any insight would be appreciated, thanks!

Spec:

{
  "@type": "StateChange",
  "changed": {
    "a3123": {
      "Email": "d35ecb040aab",
      "EmailDelivery": "428d565f2440",
      "CalendarEvent": "87accfac587a"
    },
    "a43461d": {
      "Mailbox": "0af7a512ce70",
      "CalendarEvent": "7a4297cecd76"
    }
  }
}

Actual:

{
  "changed": {
    "a3123": {
      "Email": "redacted",
      "EmailDelivery": "redacted",
      "Mailbox": "redacted",
      "Thread": "redacted"
    }
  },
  "type": "connect"
}

@rjbs
Copy link
Member

rjbs commented Feb 1, 2023

You have found a bug. We'll look into it, thanks.

@rockorager
Copy link

You have found a bug. We'll look into it, thanks.

Thanks for looking into it! I also noticed the ping and closeAfterState URL params don't seem to change the behavior in any way.

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

6 participants