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

Support for Pass Type ID #51

Open
huntermonk opened this issue Apr 19, 2017 · 15 comments
Open

Support for Pass Type ID #51

huntermonk opened this issue Apr 19, 2017 · 15 comments
Labels

Comments

@huntermonk
Copy link

huntermonk commented Apr 19, 2017

It appears that NWPusher does not support Pass Type ID certificates.

These certificates are used for sending push notifications wallet passes. You use the same certificate for signing a certificate and for sending pushes.

How could we get support for this added in?

Thanks for your consideration! I really appreciate it.

@leovandriel
Copy link
Contributor

Hi @huntermonk, I've not used such certificate yet, but it wouldn't be hard to add support. In NWSecTools.m we need to add an entry to NWCertType, [prefixWithCertType:], and a few other place.

I can do this, but I would need to know the prefix that Apple uses for the certificate name. For a regular iOS push certificate this name start with Apple Push Services:. Could you take a look inside your Pass Type certificate to see what this prefix is?

Thanks

@huntermonk
Copy link
Author

huntermonk commented Apr 25, 2017

Hey @leonardvandriel, sorry for the slow reply! I'll be much quicker on subsequent responses.

Pass Type certificates are prefixed with Pass Type ID: followed by the pass ID, which is in format pass.com.company.product.

@leovandriel
Copy link
Contributor

I added this certificate prefix. Could you check out commit 9371147 and run PusherMac to see if the certificate shows up in the dropdown?

@huntermonk
Copy link
Author

It showed, and I was able to select it. 👍🏼

When I attempted to send a push, I got the error: Unable to read failed: Read connection closed

Here's the full log:

screen shot 2017-04-25 at 4 37 41 pm

@leovandriel
Copy link
Contributor

The error indicates that the payload was pushed out, but the server disconnected (errSSLClosedGraceful) after. This is unexpected behavior, but could perhaps be okay for this kind of certificate. Did you receive a push payload on the device?

@huntermonk
Copy link
Author

Oh ok interesting.

I did not receive a payload on the device unfortunately. Anything else I should try?

@leovandriel
Copy link
Contributor

I'm not sure. A couple of maybes:

  • maybe the APNS expects a certain payload format; the docs talk about "The pass type identifier".
  • maybe the binary interface is not supported for pass type id pushes; nwpusher uses the binary interface, which is being phased out by apple.
  • maybe check the basics; production/develop? sandbox? right push token? Does this combination of certificate and token work in other services?
  • maybe it's something unrelated, like a firewall or proxy or glitch; are regular ios pushes working for you?

Sorry, that's all i got at this point. You can always step through the code to see where the error exactly occurs and what happens before. For example take a look at - (BOOL)read:(NSMutableData *)data length:(NSUInteger *)length error:(NSError *__autoreleasing *)error.

@leovandriel
Copy link
Contributor

@huntermonk I was taking a closer look at the docs (Updating a Pass). Under "Your Server Sends a Push Notification When Something Changes" it says

Send a push notification with an empty JSON dictionary as its payload to each push token.

So i was wondering: what is the payload that you're sending and have you tried variations on that? Perhaps the app needs support for zero-length payloads.

@leovandriel
Copy link
Contributor

Continuing my previous comment: try sending payload {} or even empty string. Or.. to leave the payload section out all together, modify NWNotification.m on line if (_payloadData) [self.class appendTo:result identifier:2 bytes:_payloadData.bytes length:_payloadData.length]; change if (_payloadData) to if (_payloadData.length) and send empty payload string.

@huntermonk
Copy link
Author

huntermonk commented Apr 26, 2017

Nice! Thanks for being so thorough.

We actually do have this working in our staging environment. The correct "empty" payload to send is:

{"aps": ""}
  • maybe the APNS expects a certain payload format; the docs talk about "The pass type identifier".
    As you suspected, they do require that specific format.
  • maybe the binary interface is not supported for pass type id pushes; nwpusher uses the binary interface, which is being phased out by apple.
    This is interesting! I have no idea here. I've added this to my to-do list tomorrow.
  • maybe check the basics; production/develop? sandbox? right push token? Does this combination of certificate and token work in other services?
    We do have this working in our staging environment using the same payload and certificate, so I don't think this is the problem.
  • maybe it's something unrelated, like a firewall or proxy or glitch; are regular ios pushes working for you?
    Same answer here - they are.

If I don't find anything interesting on the binary interface question, I think my best next step is to step through the code as you suggested. I am a little intimidated 😊, but it is on my list for tomorrow!

@leovandriel
Copy link
Contributor

Interesting, I wouldn't have guessed {"aps": ""}, since the aps is usually of dictionary type. Anyway, that means that the empty-payload theory is off the table (so don't mind the if (_payloadData.length) thing i mentioned in my previous post).

The APNS servers behave in mysterious ways, so it might be worth taking a closer look at what exactly you send out and what comes back. Some guidelines:

  • the sending process starts in NWAppDelegate.m under - (void)push.
  • to see what is sent exactly, step through NWSSLConnection.m under - (BOOL)write:(NSData *)data length:(NSUInteger *)length error:(NSError *__autoreleasing *)error.
  • and to see what comes back, step through - (BOOL)read:(NSMutableData *)data length:(NSUInteger *)length error:(NSError *__autoreleasing *)error
  • you can always just po the values of data, length, and status after SSLWrite(..) and SSLRead(..).

@huntermonk
Copy link
Author

I feel bad about this, but I'm not going to end up solving this. You've been excellent to work with and I wish I could do more to help, but I'm still fairly novice.

I really appreciate your help, and you've made an excellent product. I suggest it to others quite often.

I'm figuring you would rather hear this than me just not responding.

Let me know if there's anything else I should do!

@leovandriel
Copy link
Contributor

no problem, thanks for reporting the issue and taking a closer look. I'll leave this issue open and marked as bug.

@huntermonk
Copy link
Author

Great, I appreciate the understanding.

@arturfie
Copy link

Just to let you know - it works with Pass Type ID (I've got unticked Sandbox environment though)

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

No branches or pull requests

3 participants