I currently use APNS *.p8 key file and my question is about it's expiration time. I do not use *.p12 but anyone else may be interested in them also. How often should I generate new .p8/.p12 files?
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
During Blockchain Hackathon Kyiv 2020 we picked NEAR Protocol challenge and found several issues.
Accound and account keys are created in web wallet. Then you should run "near login" command at your server which should launch curl to web wallet and authorize near-cli app for accessing keys. However in our case keys weren't imported into server deployed at Digital Ocean with Ubuntu 20.0.4 and accessed via console. Near Discord channel didn't responded to our questions at all. Telegram devs chat support guys didn't helped much, their last offer was "copy keys from localstorage to json file and put into your server .near-credentials folder"
But after all - and that was amazing - a new key created at those remote machine with near addkey command - was added to those accoundID which was not authorized to use app!!! :D
enter image description here
https://examples.near.org/ - GITPOD links doesn't properly configured, not working with errors
https://gitpod.io/#https://github.com/near-examples/token-contract-as
https://gitpod.io/#https://github.com/near-examples/wallet-example
Excited that you chose to build on NEAR, but disheartened to hear about your subpar experience. NEAR is currently growing at an exponential rate and engineering resources certainly can be limited at times.
Unfortunately, if you created your NEAR account on a different machine than the one you want to store the credentials for that account on, running near login won't work. You could get around this by copying your private key from your browser's local storage to the remote machine's browser's local storage, then running near login on that machine but thats a little more work than what’s necessary. The easier, more straightforward path, would be to run near login on your local machine (the one that created the NEAR account) and copy the newly created .json file located in ~/.near-credentials to the target machine. I think that’s what the devs on Telegram you chatted with were referring to. Currently, that would be the easiest solution to that issue.
But after all - and that was amazing - a new key created at those remote machine with near addkey command - was added to those accoundID which was not authorized to use app!!! :D
Could you clarify what exactly happened here and how you performed this action? You should not be able to add a full access key to an account without an existing full access key.
Also, thank you for raising our attention to the two broken GitPod examples. There have been several updates recently to the near-sdk-as dependency these two projects rely on, and looks like something broke. I will make sure this is resolved ASAP!
Please let me know if you have any other questions, comments, or suggestions, and thank you so much for bearing with us as we continue to enhance our platform and developer tooling.
Near Discord channel didn't responded to our questions at all. Telegram devs chat support guys didn't helped much, their last offer was "copy keys from localstorage to json file and put into your server .near-credentials folder"
I would like to point out that there is no paid service with 24/7 support. People have their weekends to spend with their family and friends.
But after all - and that was amazing - a new key created at those remote machine with near addkey command - was added to those accoundID which was not authorized to use app!!!
Which key are you talking about? The 3 keys you have on the screenshot were sequentially used to sign the next transaction adding the new key:
ETQeNJrRiqbcuqJyrfDTh1EYAUAetXZsnuuiEH8T6mnc transaction created the account with ed25519:HBi7mgC... key.
8heaysv121qhFjktwRm9ftF4jA7dgcYRHvKkcCnhXFVT transaction signed with ed25519:HBi7mgC... key (added in (1)) adds a new ed25519:DmNJSxx... full-access key.
DUp8VJ9aoUyC6r8ira6udpgHYxsKJWi3LXkxxn5btLW2 transaction signed with ed25519:DmNJSxx... key (added in (2)) adds a new ed25519:DoMh6uC... full-access key.
I have an app which uses Parse and I want to migrate it to Firebase. I was extended the parse installation objects to send customized push notifications. I'm wondering if I can migrate these parse installation objects to Firebase and use it from Firebase.
There is no cookie cutter click-though way to import an app that uses Parse.com into Firebase. The products are too different for that.
There are however migration guides for developers looking to migrate their iOS and Android apps on the Firebase site: https://firebase.google.com/support/guides/#migrating_from_parse
There is also a repo with parse-migration-tools from Firebase: https://github.com/firebase/parse-migration-tools
Finally have a look at this question, where experienced developers chimed in already: How to migrate data from Parse.com to Firebase
[Disclaimer: Former lead of Parse Push. Author of parse-migration-tools]
I'm a bit nervous that you're out of luck if you're referring to "installation Ids". Firebase supports iOS and Android. Android devices aren't going to be easy to port for a few reasons, though iOS can be done without too much work. Let's break it down by the push backend:
Most people who talk about "installation Ids" are talking about Parse's self-hosted push network (PPNS or Parse Push Notification Service). This is hosted at push.parse.com and will go away in January. There's nothing anyone can do to keep those devices connected. As an FYI you'll also realy want to update your apps to disable PPNS because it will likely drain your customers' battery when they have a background service repeatedly trying to connect to a URI that isn't going to exist anymore.
If you're using GCM directly, you're still out of luck actually. Parse uses a version of GCM that's too old to work with Firebase. I tried to help fix it, but we weren't able to upgrade to GCM v4 and keep the Parse design style. The new Firebase SDK makes it possible to fix the issue and keep the Parse design requirements, but I'm far too overextended to build this right now. If someone wants to grab a shovel, I'd be glad to explain the right design.
iOS will actually work. I intended to make this turnkey in parse-migration-tools but won't have time until the end of the year. Firebase Cloud Messaging has a batchImport API for importing iOS tokens. I also wrote support for batchImport in parse-migration-tools to help you import your devices (and other data) faster. If I were migrating Parse Push from iOS, I would personally write a migration and bulkImport function that used batchImport to create GCM tokens and subscribed Parse Channels as FCM topics (note the batchAdd method; it may help you more efficiently do your initial import).
This should do the trick:
https://firebase.google.com/docs/cloud-messaging/ios/client#import_existing_user_apns_tokens
You can just importat all of the existing users device id's and FireBase will generate unique id's for them.
I have an application which is hosted on Amazon (AWS) server and an app admin on godaddy.in admin. I can send push notification using parse server API (https://api.parse.com/1/push') to app user.
My question is:
Is parse server push notification also going to stop by 28 Jan 2017?
Can I send particular user push notification using parse server?
Thanks
the answer to your questions are:
Yes push notifications will also not going to work since the push is done through the parse.com server which will not be available. so parse.com with all of its services will not be available.
Sure you can. The current limitation is that when you send push with parse-server you must use your master key so in order to do it you need to create a cloud code function and from there to write the code that handle the push notifications. I already gave an answer on how it can be done .. you can read the detailed answer in here
It seems like you are yet to migrate your app from parse to your own self hosted environment. More details available here
After you might have done that, visit the Push Wiki page on how you can configure your push notification. It's a fairly easy process.
I have a custom client that i use to get Lets Encrypt certificates but i can't work out the proper protocol to renew the certificates. The versions of the spec that i have found seem very vague on the exact renewal process.
Is the renewal process any different from a new certificate request? Are there steps i can skip or is it totally different? I am currently using the DNS based verification if that makes a difference. At the minute i am just requesting a new certificate following the full process but i am not sure if that the correct way or over kill or a very bad thing to do.
This will depend on your client, however, the steps should be similar to the initial request. The difference is that you don't have to regenerate a private key or a CSR if you saved them and your private key did not get compromised.
This makes it very easy to automate the renewal process.
I believe they will be adding automatic renewal scripts in the near future, there is a basic bash script posted on the front page of the website at the moment.
I'm using parse.com is there a way to reset the client and rest keys?
I reset the master key, but that didn't seem to do it. (I verified that the Master key changed).
I could delete the app since it isn't yet in production, but was hoping there was a less draconian alternative
Your only option is to e-mail parse.com support and ask them to do it. There is no option on the web interface to do it. Generally changing these keys breaks clients so it isn't something you do regularly (if ever).