Planning on Adding Sign In With Apple?

packages
10

Sweet! Please consider adding it to linked accounts:

1 Like
11

Sure. It need some work first though.

Do you have any input on how to best implement the fix for the post body data I mentioned in my post?

12

I would check Meteor PRs, if I remember correctly there was something along those lines.

1 Like
13

Ah! Here is the PR that should add that capability:

2 Likes
14

Looks like the package is out:

https://atmospherejs.com/bigowl/accounts-apple

3 Likes
15

Yes it’s out and working as intended on chrome, firefox, safari and ios browsers (ie/edge not tested but should work).

I still haven’t had time to look into cordova. Our app is web only and my time is limited…
Started to look at meteor-link-accounts and that is something we need to have working.

3 Likes
16

If you need help with integrating into link-accounts, let me know, but it should be pretty straight forward.

17

Thanks!
Yes looks straight forward.
I want to have link-accounts working as intended in our app first and then I’ll create the apple integration.

1 Like
18

@jramer Is this still working for you? Any new changes?

19

Yes. I have it running in production.

And my PR has been included in 1.10 which will remove the need to use my fork of the oauth-package.

I still haven’t had the time to look at making it work in Cordova, or with link-accounts.

1 Like
20

Thanks for your answer! Apple still pushing this for end of April 2020.

21

How do you handle callbacks with this?

Looks like quave has moved this into the mainstream, since you can now signInWithApple

Install these two https://atmospherejs.com/quave/accounts-apple, https://atmospherejs.com/quave/apple-oauth

meteor add quave:accounts-apple
meteor add quave:apple-oauth

Set up the config in settings.json alongside facebook and google oauth per this guide.

settings.json :

"apple": {
  "teamId": "yyexamplexx",
  "clientId": "com.example.client",
  "keyId": "zzexamplewq",
  "secret": "zxcvsdfasdfexamplezlongstrxcvsdfasdf",
  "redirectUri": "https://example.com/apple-redirect"
},

Client :

continueWithApple = () => {
  Meteor.loginWithApple({}, function(err, res) {
    if (err) {
      console.log(err);
    }
    //running ok
  });
};

<Form.Button
  id="appleid-signin"
  fluid
  basic
  className="continue apple"
  data-color="black"
  data-border="true"
  data-type="sign in"
  onClick={() => {
    this.continueWithApple();
  }}
>

Server:

// I had to initialize the loginWithApple…

setupAppleConfig: async () => {
  console.log("setting up apple config for login...");
  Accounts.loginServiceConfiguration.remove({
    service: "apple"
  });
  Accounts.loginServiceConfiguration.insert({
    service: "apple",
    clientId: "com.example.client",
    responseType: "code",
    responseMode: "query",
    redirectUri: "https://example.com/apple-redirect",
    scope: "name email"
  });
},

Opens a popup, which prompts you to login, then redirects you to the redirectUri, but how do you handle this redirect auth?

22

I’m working on getting this integrated with iOS app @filipenevola (have used quave’s loginWithApple meteor packages). I’ve been reading lot about this and based on a few posts (post 1 , post 2 …), have realized that if you’re logging in with the Web app you need to use Client Id (aka Service Id), vs on iOS app use App Id.

So what I’ve done is that when I run the compile, which looks like:
meteor build ../output-app-folder --mobile-settings settings-staging.json --server https://example.meteorapp.com
I need to set the clientId inside the settings-staging.json to the AppId instead of clientId (Service Id):

      "apple": {
        "secret": "-----BEGIN PRIVATE KEY-----\nexample\nexample\nexample\nexample\n-----END PRIVATE KEY-----",
        "redirectUri": "https://www.example.meteorapp.com/_oauth/apple",
        "clientId": "com.ExampleAppId.url",
        "teamId": "WexampleT",
        "keyId": "UexampleU",
        "scope": "name%20email",
        "responseMode": "form_post",
        "responseType": "code",
        "service": "apple"
      }

However, I am only getting back the apple user’s information without the name and email for iOS, whereas web I’m getting everything!

Apple User info I get:

{
  "_id": "Wexampleuserf",
  "createdAt": "2020-08-10T20:14:35.084Z",
  "services": {
    "apple": {
      "accessToken": "aexample.0.mssss.LexampleA",
      "expiresAt": 1697024073077,
      "id": "001100.0f00f00f00f00f00f00f00f0.2000",
      "idToken": "elongstringasdflongstringasdflongstringasdflongstringasdflongstringasdf..._USc",
      "name": " ",
      "refreshToken": "rexample.0.mssss.LexampleA_555aaaa",
      "scope": "name email"
    }
  }
}

How can I get the full user details?

23

@mryoda did you get this sorted out?

@jramer is this integrated w/ link-accounts?

24

I haven’t taken the time to integrate it with link-accounts yet. But it’s still something I want to have working.

@mryoda
Apple only gives name and email on the first signup.
For testing purposes you can go to your Apple ID settings, appleid.apple.com, and press “stop using Apple ID” for that App/Website.
Security-> APPS & WEBSITES USING APPLE ID.
That will reset it and you will get name and email once more for that Apple ID.

I haven’t looked at qualias code, they’ve forked mine. But it sounds like we need a new setting for AppId

2 Likes
25

I just saw that @filipenevola is working on the quave version of apple-oauth, to integrate it with Cordova. Does this mean that there is a chance that we’ll see support for “Sign in with Apple” as a standard login provider in Meteor soon?

It would be super-nice if the great work by @jramer and the quave fork would be consolidated into a new standard package somehow.

4 Likes
28

I’ve successfully implemented the Apple OAuth workflow and it works in Chrome and Firefox.

However, on macOS Safari, there is no popup. Instead, the authentication is shown in-place, as an overlay to the web app. This breaks the workflow and no sign-in is possible. It seems as if Meteor is not prepared for this login scenario?

I had seen the comment by @jramer on that, but since quavedev:apple-oauth has been pushed to Atmosphere in the meantime, I made the naive assumption that this has been fixed in the meantime. Obviously not.

The thing is: macOS Safari is a pretty important browser for Sign in with Apple… :slight_smile:

(I also noticed that on my testing machine the redirect goes back to localhost instead of the domain of my tunnel provider, localtunnel, although the original website is pulled from there. I have no idea why this happens.)

EDIT: Found out that only dev machines are affected. If you try this out on a real prod server, it works. The UX is a bit strange, though, because the redirect shows the login screen again briefly until the logon takes place. But it works.

2 Likes
29

Yes this should work as I have my package running in production on https://bubotree.com.

30

I made a PR today to support the accounts-apple in meteor-link-accounts:

There are two caveats however:

The workflow fails on macOS / iOS Safari, since these browsers uses a native login dialog instead of a popup. After the login succeeds, the redirect URI replaces the page and thus creates a new user instead, like in a regular login / signup scenario. I haven’t found a way yet to avoid this.

The other one is rather cosmetic and related to the quave package, as they have changed the signature of the requestCredential() function.

I did not have time to test it with the bigowl variant, but it should work, as both versions don’t differ much. So, if anyone wants to give it a try, happy to hear your feedback.

3 Likes
31

Just documenting the answer here as well:

These two packages should do the work:

Feel free to open issues on them if you find problems.

1 Like