Is anyone now online able to perform receipt validation in a Mac application?
Have you used the ASN generated files in the application?
Are you able to produce a sample receipt by automatic popup of the iTunes authentication?
The best way I know to check receipts is by letting Receigen generate the code - different for each new version. It's probably more secure than what you can develop in a reasonable time.
I have it working, but i am using open source code to do it.
Using this code in your main , and changing your app bundleID/version, it validates the receipt.
In this question you can see the code i used.
Mac App Store Receipt Validation Code?
I've got an example receipt at my question here (Can Purely On-Device In-App Purchase Receipt Validation Be Done With iOS6?). I've generated the ASN files and am trying to use them now. I used the compiler here. I'm not sure if it all works though, just starting testing in earnest now.
Chris.
Related
I need to embed billing into the libtorrent. So I need to know when node B successfully uploads a block to node A. But according to libtorrent docs, alert block-uploaded-alert is posted when a block intended to be sent to a peer is placed in the send buffer. So in fact the block is not yet uploaded when this alert is posted. Is there a way to know whether the upload was successful?
P.S. Can I limit the number of blocks which are uploaded to the same peer at the same time?
I'm dealing with a similar issue. From what i've discovered there's no implementation for this use case in libtorrent yet. The answer from arvid (the creator of Libtorrent) in this question: Get alerts for upload activity with libtorrent (rasterbar) may give us a hint about how to achieve this.
Since i'm looking forward to implement this, i'm open to discuss about it and probably make a PR on libtorrent repo to achieve it: https://github.com/arvidn/libtorrent/issues/6247.
i gust curious maybe someone heard about solution how to get Report (SSRS Report) in Plugin (i want to export it in pdf from CRM and save in Sharepoint).
I have tried following solution:
https://community.dynamics.com/crm/f/microsoft-dynamics-crm-forum/247210/how-to-run-the-crm-report-through-sdk?pifragment-97030=1#responses
this one is not working anymore because of authentication. I tried to authentificate my user in WebClient inside plugin but no luck. Maybe someone know how to do it
There is an excellent article/blog posted by Bob Guidinger for Generating Report and sending Email for D365 Online.
Once you get first step running, you can extend it to perform you specific operation.
Blog mentioned about Azure function and plugin (combination).
Scheduling Reports in Dynamics 365 - Part 1
I tried this for one of my project and it worked fine with me. This shall be a bit learning curve if you do not know how to create azure functions and some small parts.
Happy Coding!!
Make sure to upvote, Accept if this helps!!
I'm using James Montemagno's Plugin.InAppBilling library for Xamarin to do iOS and Android in-app subscriptions. It has worked mostly correctly so far, except that once in a while, on iOS only, InAppBillingPurchase.PurchaseToken comes back null from calls to PurchaseAsync and GetPurchasesAsync.
For example, in my Restore Purchases logic, I have code similar to this:
var purchases = await CrossInAppBilling.Current.GetPurchasesAsync(ItemType.Subscription);
// Sometimes we receive purchases with no PurchaseToken.
// Can't verify the purchase without a token.
var verifiable = purchases.Where(p => !string.IsNullOrWhiteSpace(p.PurchaseToken));
At this point, verifiable sometimes has a different count (0) than purchases (1).
So far, this has seemed to happen when the user purchased using either store credit or a gift card, and only on iOS.
Also, I'm not sure if this bears on the problem, but I am not using the overloads of PurchaseAsync and GetPurchasesAsync which take IInAppBillingVerifyPurchase, because I use server-side verification exclusively (no client-side verification). My workflow is to make the purchase, add the resulting InAppPurchase object to a queue for processing, and then send it to our server as a separate step, for validation and association with the user's account. However, if this is not a valid workflow or if it is known that sometimes PurchaseToken data will be available via IInAppBillingVerifyPurchase.VerifyPurchase but not attached to the InAppBillingPurchase objects returned from the methods above, I would certainly like to know about that. (For what it's worth, I've read the documentation and don't see anything that suggests this.)
Thanks in advance for any help.
Okay, I think I've learned enough to provide useful information for anyone else dealing with this issue.
First, I've figured out what Apple means by "iOS 6 style" and "iOS 7 style" receipts. These do not refer to the version of iOS that creates the receipts. (My up-to-date iOS 12 device still can and does generate "iOS 6 style" receipts.) Instead, these refer to two different receipt formats that were introduced in the respective iOS versions.
iOS 6 style receipts come from SKPaymentTransaction.transactionReceipt and contain information about one specific transaction. This field is now deprecated by Apple.
iOS 7 style receipts come from the app bundle, via the location named in NSBundle.mainBundle.appStoreReceiptUrl. These receipts contain a full manifest of all purchases ever made by the user. The receipts don't expire either -- you can always send them to Apple for validation (though, obviously, individual transactions contained within might show as expired in the response). These are the receipts you should prefer.
The reason this is important is that if you're using the Plugin.InAppBilling library, the InAppBillingPurchase object you get from calling something like PurchaseAsync contains the deprecated iOS 6 style receipt in its PurchaseToken field.
I'm still not sure why it is sometimes present and sometimes null, but seeing as the underlying source of the data is deprecated, it's probably safe to assume that this can and will happen. Therefore, it probably makes sense to cut over to the iOS 7 style receipts as soon as possible.
Note that when you call PurchaseAsync, if you specify an implementation of IInAppBillingVerifyPurchase, your IInAppBillingVerifyPurchase.VerifyPurchase method will receive the newer iOS7 receipt instead. However, the InAppBillingPurchase object returned by PurchaseAsync still gets an iOS 6 style receipt (if it gets anything at all).
Personally, I like the InAppBillingPurchase object itself. It has useful information packed into a convenient package. Since I want to keep the serialized InAppBillingPurchase objects in a queue so that I can retry validation if there are problems with our servers, connectivity, etc, what I'm doing is immediately replacing the PurchaseToken property with the iOS 7 style receipt that I manually retrieve from the bundle.
If you do this, be sure that your code handles the slightly different formats of the iOS 6 and iOS 7 receipts properly. (Our earlier attempts had some errors stemming from not properly understanding what these terms meant.)
I hope this is useful to someone out there. Good luck!
I'm trying to use a NokiaMaps for windows phone 7 and I've tried follow from this sites:
http://developer.nokia.com/Community/Wiki/Nokia_Maps_for_WP7_using_Bing_Map_Control.
But "MapTileLayer" as Hybrid,Physical,Street,Satellite... does not work !
I think this problem is UriFomat but i can't solve.
Can you please tell me the reason ?
For using the Bing Map control successfully you need to obtain a Bing Map Token (NokiaMapTile.cs, topic 4). You can obtain it here: https://www.bingmapsportal.com/
Beware that when requesting the token you need to specify the same app name as the test one (in this case NokiaMaps).
And be sure to update the .cs and .xaml files with your newly created token data.
Regards,
I tried publish my app: http://pomidoro.codeplex.com/ on Windows Store and certification failed because:
'Your app doesn't meet requirement 1.1.
Comment from tester: This app didn't appear to provide value or didn't seem useful to the reviewer.'
Is that means that I do not have any chances to publish it anymore?
No, you can make some tweaks and publish again. Here are some thoughts:
It may be an issue of marketing, and modifying the description that you submit with your application will fix the issue. Your description at http://pomidoro.codeplex.com is pretty good, but maybe you could add some data around how it helps you work more efficiently in case the reviewers aren't familiar with Pomodoro. There are tips on writing a good description/app listing here.
Otherwise, you could add some extra features to the app so it's more than just a timer. Can the user record their whole To Do list in the app, and then choose what to focus on during the pomodoro from that? Or, allow them to rank each pomodoro as effective/not effective after the timer goes off and keep historical data so they can see what times of day they are most effective? And so on...
Here is the first post in a blog post series on common certification failures for the Windows Store and how to fix them which might also be useful.
Good luck!