shoshins / apple-receipt Goto Github PK

The verifyReceipt endpoint is deprecated.

https://developer.apple.com/documentation/appstorereceipts/verifyreceipt

Defined as
apple-receipt/Apple.Receipt.Parser/Services/AppleReceiptParserService.cs
internal class AppleReceiptParserService : IAppleReceiptParserService
So class AppleReceiptParserService can not be used from other library.

#12 - Details here

I'm using Autofac for wiring up my IoC / DI-Container. As all the interfaces and classes do have the access modifier "internal" I'm not able to register them using the ContainerBuilder from Autofac. Any chance to get thad adjusted?

Thank you in advance for your time!

using Apple.Receipt.Parser.Services;
using Autofac;

namespace SubscriptionMicroservice.Application.IoC;

public class AppleReceiptParserModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder.Register<IAppleAsn1NodesParser, AppleAsn1NodesParser>().InstancePerLifetimeScope();
        builder.Register<IAsn1NodesParser, Asn1NodesParser>().InstancePerLifetimeScope();
        builder.Register<IAsn1ParserUtilitiesService, Asn1ParserUtilitiesService>().InstancePerLifetimeScope();
        builder.Register<IAppleReceiptParserService, AppleReceiptParserService>().InstancePerLifetimeScope();

    }
}

According to this documentation, there're some fields that are returned from the verifyReceipt endpoint, but do not present in models:

• in_app_ownership_type
• subscription_group_identifier
• promotional_offer_id

The recommended way from Apple to verify receipts is to first try the production URL. If fails try sandbox URL. Details https://developer.apple.com/documentation/storekit/in-app_purchase/validating_receipts_with_the_app_store

It would be amazing to have mode Both, as now it is pretty hard to use the given approach.

AppleReceiptVerificationResult.Status is marked as obsolete.
However if something goes wrong it is populated with data leaving AppleVerificationResponse property equal to null.

I propose it not to be obsolete or change error handling behaviour.

Hi,

I've just started running some tests using this library and unfortunately, none of it seems to work.

I've run this in Startup.cs

'''
var verificationType = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") == "Production" ?
AppleReceiptVerificationType.Production : AppleReceiptVerificationType.Sandbox;

var appleStoreKey = Configuration.GetValue("AppSettings:AppleSharedSecret");

services.RegisterAppleReceiptVerificator(x =>
{
x.VerifyReceiptSharedSecret = appleStoreKey; // Apple Shared Secret Key
x.VerificationType = verificationType; // Verification Type: Sandbox / Production
x.AllowedBundleIds = new[] {"myBundleId"}; // Array with allowed bundle ids
});
'''

When I resolve the service and execute:

byte[] data = Convert.FromBase64String(model.PurchaseToken);
AppleAppReceipt receipt = _receiptParserService.GetAppleReceiptFromBytes(data);

Receipt is always null.

var verificationResult = await _appleReceiptVerificatorService.VerifyAppleReceiptAsync(model.PurchaseToken).ConfigureAwait(false);

var r = await _appleReceiptVerificatorService.VerifyAppleSandBoxReceiptAsync(model.PurchaseToken).ConfigureAwait(false);

None of these work either as a result, I guess, of the parser problem.

Unfortunately, I'm now on a crazy deadline so will be removing this library as I just cannot wait for any resolution.

I guess there is some gaps in the documentation or setup.

Hello. Is this library still supported? I am getting an exception while trying to use this library along with a newer Refit version(6+) that is being used in my project. The problem occurs on resolving IAppleReceiptVerificatorService. Downgrade of Refit fixes the issue but it is not desirable in my case. Are there any plans to upgrade packages in your project? Thanks.

System.InvalidOperationException: IRestService doesn't look like a Refit interface. Make sure it has at least one method with a Refit HTTP method attribute and Refit is installed in the project.

hello @shoshins and @trejjam
First of all thank you for creating these packages, I do appreciate your work and it being well crafted.

On to the issue:

My Setup:
OS: MacOS 10.14.6
.NET Core SDK version: 3.1.302
Package: Apple.Receipt.Verificator version 2.0.2

Apple.Receipt.Verificator.Modules.AppleReceiptVerificatorExtension LOC 26:

var options = serviceProvider.GetRequiredService<IOptionsSnapshot<AppleReceiptVerificationSettings>>();

throws:

System.InvalidOperationException: Cannot resolve scoped service 'Microsoft.Extensions.Options.IOptionsSnapshot`1[Apple.Receipt.Verificator.Models.AppleReceiptVerificationSettings]' from root provider.

When resolving injected IAppleReceiptVerificatorService in a ASP.NET Core Api Controller (for example).

Steps to reproduce:

create new web api project:

dotnet new webapi -n "webapiappletest"

add the package

cd webapiappletest/
dotnet add package Apple.Receipt.Verificator --version 2.0.2

add in Startup.cs in ConfigureServices:

            services.RegisterAppleReceiptVerificator(options =>
            {
                options.VerifyReceiptSharedSecret = "xxx";
                options.VerificationType = AppleReceiptVerificationType.Sandbox;
                options.AllowedBundleIds = new[] { "com.example.app" };
            });

inject IAppleReceiptVerificatorService in WeatherForecastController:

        private readonly ILogger<WeatherForecastController> _logger;
        private readonly IAppleReceiptVerificatorService _appleVerificationService;

        public WeatherForecastController(ILogger<WeatherForecastController> logger, IAppleReceiptVerificatorService appleVerificationService)
        {
            _logger = logger;
            _appleVerificationService = appleVerificationService;
        }

open in browser:
http://localhost:5000/weatherforecast

result:
throws exception

System.InvalidOperationException: Cannot resolve scoped service 'Microsoft.Extensions.Options.IOptionsSnapshot`1[Apple.Receipt.Verificator.Models.AppleReceiptVerificationSettings]' from root provider.

expected result:
Does not throw exception ;)

Possible reason for an exception:

Using IOptionsSnapshot which is a scoped service while configuring a singleton http client Refit in Apple.Receipt.Verificator.Modules.AppleReceiptVerificatorExtension:

        public static IServiceCollection RegisterAppleReceiptVerificator(this IServiceCollection services, Action<AppleReceiptVerificationSettings>? configureOptions = null)
        {
            services.RegisterAppleReceiptParser();

            if (configureOptions != null)
            {
                services.Configure<AppleReceiptVerificationSettings>(configureOptions);
            }

            services.AddRefitClient<IRestService>()
                .ConfigureHttpClient((serviceProvider, httpClient) =>
                {
                    var options = serviceProvider.GetRequiredService<IOptionsSnapshot<AppleReceiptVerificationSettings>>();

                    httpClient.BaseAddress = new Uri(options.Value.VerifyUrl);
                });

            services.TryAddScoped<IAppleReceiptVerificatorService, AppleReceiptVerificatorService>();

            return services;
        }

When swapping IOptionsSnapshot with either IOptions or IOptionsMonitor the exception does not occur. Official docs on IOptions...: link

Another thing is the app.config file mentions Autofac dependency but it doesn't do anything in the .NET Core environment, I guess. Seems like a leftover from .NET Framework.

Possible fix

1. Using IOptions or IOptionsMonitor with its consequences (refer to docs: link)
2. Creating a local scope and getting the IOptionsSnapshot from the scope:

            services.AddRefitClient<IRestService>()
                .ConfigureHttpClient((serviceProvider, httpClient) =>
                {
                    using (var scope = serviceProvider.CreateScope())
                    {
                        var options = scope.ServiceProvider.GetRequiredService<IOptionsSnapshot<AppleReceiptVerificationSettings>>();
                        httpClient.BaseAddress = new Uri(options.Value.VerifyUrl);
                    }
                });

3. (my personal preferred) Using IHttpClientFactory instead of external dependency Refit (if I understand correctly) and moving the logic deciding which Apple Receipt Verify Url (Prod or Sandbox) to use into the Verifying logic itself either by getting it from the already injected IOptionsSnapshot<AppleReceiptVerificationSettings> in the Apple.Receipt.Verificator.Services.AppleReceiptVerificatorService or passing it even down from AppleReceiptVerificatorService.VerifyAppleReceiptAsync(string receiptData) something like AppleReceiptVerificatorService.VerifyAppleReceiptAsync(AppleReceiptVerificationType verificationType, string receiptData) down to the HttpClient instance.
   That way we get rid of Refit dependency and are more flexible about where to send the receipt data (like when Apple Server responds with wrong environment status and we gotta resend it to the correct one, which btw the package does not allow in its current state).

Let me know what you think and if you accept PRs.
Cheers!

"Hi, I noticed a bug in your code. For pending subscription information it seems to be looking into the individual receipts instead of the "pending_renewal_info".

If you look at the below JSON structure

[JsonProperty("auto_renew_product_id")] public string SubscriptionRenewProductId { get; set; }

https://github.com/shoshins/apple-receipt/blob/7734e6e485657ba3ff69bf13a5ff7cbfc1953589/Apple.Receipt.Models/AppleInAppPurchaseReceipt.cs

And from my testing it is ALWAYS null even when it is available in the apple receipt and other Apple Receipt C# parsers return the value... but your framework always returns the SubscriptionRenewProductId as null.

Can this be fixed soon? We urgently need this to be populated. We have rewritten our code using a different framework while we waited a long time for you to fix this and it never seemed to get fixed." (C)