I am integrating HMS IAP with my own server, I tested a subscription purchase and initiated my server to call IAP server API ({rootUrl}/applications/purchases/tokens/verify) to verify the purchase token but I received this message:
{"responseCode":"6","responseMessage":"paymentToken siteID invalid"}
What is "paymentToken siteID invalid"? Am I missing something?
The IAP server API that you used is for verifying the purchase token for the non-subscription order services. That is why you receive that message.
You should use subscription service API instead - {rootUrl}/sub/applications/v2/purchases/get
You can read more about the api documents here.
Here is an example:
POST /sub/applications/v2/purchases/get
Content-Type: application/json; charset=UTF-8
Authorization: Basic QVQ6Q1YzQ1NPbVlBaGwrZUtRWExtMTBVV2pyWXZHTVF4MmYvcVMya1B0ZElLY3UwaFJrdFNTMmxwdk1FQkIyYldXWGt0REVaR3I4UjFUTTRLMVlmNXdwWU80RG04THdXQWxjaFhEYjBMUjBNTUJtWnFYcGFtazc3THN3UnFJbkhHK28xekdqRzNSMg==
Accept: application/json
Content-Length: 171
{
"purchaseToken": "00000173741056a37eef310dff9c6a86fec57efafe318ae478e52d9c4261994d64c8f6fc8ea1abbdx5347.5.3089",
"subscriptionId": "1581789719266.D40972AC.3089"
}
Please also refer to this document - Verifying the Purchase Token for the Subscription Service
Related
I am making a mobile app with React Native (it is not submitted yet)
I want to verify apple payment according the this page (https://developer.apple.com/documentation/appstorereceipts/verifyreceipt)
I'm making test with Postman to post data but getting response "status": 21002.
My request:
"receipt-data" : "MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwGggCSABIIBQjGCAT4wDwIBAAIBAQQHDAVYY29kZTALAgEBAgEBBAMCAQAwHAIBAgIBAQQUDBJhcHAucWlyYXQuc2hlbG9zZXIwCwIBAwIBAQQDDAE2MBACAQQCAQEECFq3r/0DAAAAMBwCAQUCAQEEFLyIGyXi54C2cOgT2Xh8UZTtxHi4MAoCAQgCAQEEAhYAMB4CAQwCAQEEFhYUMjAyMS0wNy0xN1QxNDo0OTo0NlowdwIBEQIBAQRvMW0wDAICBqUCAQEEAwIBATAuAgIGpgIBAQQlDCNhcHAucWlyYXQuc2hlbG9zZXIuYnV5Ym9vay50ZXN0LjAwMTAMAgIGpwIBAQQDDAExMB8CAgaoAgEBBBYWFDIwMjEtMDctMTdUMTQ6NDk6NDZaMB4CARUCAQEEFhYUNDAwMS0wMS0wMVQwMDowMDowMFoAAAAAAACgggN4MIIDdDCCAlygAwIBAgIBATANBgkqhkiG9w0BAQsFADBfMREwDwYDVQQDDAhTdG9yZUtpdDERMA8GA1UECgwIU3RvcmVLaXQxETAPBgNVBAsMCFN0b3JlS2l0MQswCQYDVQQGEwJVUzEXMBUGCSqGSIb3DQEJARYIU3RvcmVLaXQwHhcNMjAwNDAxMTc1MjM1WhcNNDAwMzI3MTc1MjM1WjBfMREwDwYDVQQDDAhTdG9yZUtpdDERMA8GA1UECgwIU3RvcmVLaXQxETAPBgNVBAsMCFN0b3JlS2l0MQswCQYDVQQGEwJVUzEXMBUGCSqGSIb3DQEJARYIU3RvcmVLaXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbf5A8LHMP25cmS5O7CvihIT7IYdkkyF4fdT7ak9sxGpGAub/lDMs8uw5EYib6BCm2Sedv4BvmDWjNJW7Ddgj1SguuenQ8xKkLs89iD/u0vPfbhF4o60cN8e2LrPWfsAk4o257yyZQChrhidFydgs5TMtPbsCzX7eVurmoXUp0q+9vQaV+CY26PT3NcFfY7e/V2nfIkwQc7wmIeGXOgfKNcucHGm4mEvcysQ27OJBrBsT8DeWVUM2RyLol9FjJjOFx20pF8y0ZlgNWgaZE7nV3W1PPeKxduj5fUCtcKYzdwtcqF98itNfkeKivqG2nwdpoLWbMzykLUCzjwvvmXxLBAgMBAAGjOzA5MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgKEMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMDMA0GCSqGSIb3DQEBCwUAA4IBAQCyAOA88ejpYr3A1h1Anle5OJB3dlLSqEtwbrhnmfuzilWf7x0ouF8q0XOfNUc3u0bTdhDy8GnszWKZcflgioRIOMS9i2cluatsM2Wt2MKaeEgP6czBJw3Gz2Q8bYBZM4zKNgYqERuNSc4I/2bARyhL61rBKwlWLKWqCQN7MjHc6IV4SM7AxRIRag8Mri8Fym96ZH8gLHXmTLES0/3jH14NfbhY16B85H9jq5eaK8Mq2NCy4dVaDTkbb2coqRKD1od4bZm9XrMK4JjO9urDjm1p67dAgT2HPXBR0cRdjaXcf2pYGt5gdjdS7P+sGV0MFS+KD/WJyNcrHR7sK5EFpz1PMYIBjzCCAYsCAQEwZDBfMREwDwYDVQQDDAhTdG9yZUtpdDERMA8GA1UECgwIU3RvcmVLaXQxETAPBgNVBAsMCFN0b3JlS2l0MQswCQYDVQQGEwJVUzEXMBUGCSqGSIb3DQEJARYIU3RvcmVLaXQCAQEwDQYJYIZIAWUDBAIBBQAwDQYJKoZIhvcNAQELBQAEggEAddOQmwBnzKaO548oPeu6hcixmqsU5cvXJx18opRxBTGaYXPUUB+OueRUKh0a+mxMUs7acaDX3Wo1iC2+a0MyNYeBD8V8FpZdU6A2BbQU+zGjqMYxPPc88NHwqBCgXD/RnIlR6jgKJyZu2gI6yDRgwm3H8VmRbx4UrQlizfP0/hkzPBAqgdDoCzEudu0QVnrSpntKSd3Yl+sUEsv9zm+fZUf/tQ1PQmpLHgIzfdB3x9l4zB289uToF0dsHpY8BgOVe8cRERf0xZHOjCazE0ihNTp3+45lAaUIk0Slzj2GM6uaI3oYqMcHjWTBov9JF4ISvaC/N8SC8bMGX+VIAqXDmwAAAAAAAA==",
"password": "702a98fc92d0460bbd6aaf18c9b1ae0d",
"exclude-old-transactions" : false
}
And response:
"status": 21002
}
I tried both https://buy.itunes.apple.com/verifyReceipt and https://sandbox.itunes.apple.com/verifyReceipt but response didn't change.
I created secret key for app. How can I verify receipt, what is the missing for verification?
I am using Twilio programmable Fax api to send fax messages from my application.
I am not facing any issue while sending faxes when I provide a public url with out any authentication as mediaUrl for sending the fax. But when I pass a url secured with basic authentication as the mediaUrl for the send fax api, the fax sending is getting failed.
"status": "failed",
I have debugged the code on the server on which the mediaUrl accesses, and could find that Twilio is not at all sending a request with "Authorization" header.
As per Twilio documentation,
You may provide a username and password via the following URL format.
https://username:password#www.myserver.com/my_secure_document
Twilio will authenticate to your web server using the provided
username and password and will remain logged in for the duration of
the call. We highly recommend that you use HTTP Authentication in
conjunction with encryption. For more information on Basic and Digest
Authentication, refer to your web server documentation.
If you specify a password-protected URL, Twilio will first send a
request with no Authorization header. After your server responds with
a 401 Unauthorized status code, a WWW-Authenticate header and a realm
in the response, Twilio will make the same request with an
Authorization header
I am giving the mediaUrl in the same format as required by Twilio. But the fax is getting response as failed. Kindly provide your valuable suggestions to help me resolve the issue.
My server is sending the 401 response as given below when Twilio accesses the mediaUrl without Authorization header,
Http response header for 401
Status Code: 401 Unauthorized
Content-Length: 34
Content-Type: application/xml
Date: Wed, 30 Aug 2017 12:38:41 GMT
Server: Apache-Coyote/1.1
WWW-Authenticate: Basic realm="My Realm"
Response body
<message>Invalid credentials</message>
Update
Good news! Media URLs in Twilio Programmable Fax now support basic authentication. This has been implemented and deployed, so this should no longer be an issue.
Original answer
Twilio developer evangelist here.
After some internal investigation I've found out that this is a known issue.
It was in fact raised by your support ticket that you sent in. Good news is that since this is known it will be getting some attention and the team will contact you once it is sorted.
To answer this question differently, I'm just using Signed URLs on Google Cloud, which provide a long token that grants temporary access for a specific file. You can set this to grant access for 10 minutes, which should be more than enough time.
AWS appears to offer a similar solution.
I am having trouble starting a Microsoft Graph webhook subscription (for a mailbox in particular). When initiating the subscription it appears as though Microsoft accepts all of the parameters I am sending to configure the subscription but fails the total subscription because it is receiving a non 2xx response from the endpoint I have configured.
The reason my endpoint is sending a 401 back to Microsoft is because their POST that includes the subscription validation token is missing the clientState.
I am using the clientState key-value pair to authenticate all the communication between Microsoft and my endpoint. If my endpoint does not see the correct clientState it will return a 401.
Any ideas on what I might be missing or if I should go about this in a different way? In my opinion allowing my endpoint to accept unauthenticated GET/POST's is not an option.
Example request body using POST method including the API key in the header:
{
"changeType": "created",
"clientState": "testClientState",
"resource": "users/<UserName>/messages",
"expirationDateTime": "2017-08-10T10:24:57.0000000Z",
"notificationUrl": "<EndpointURL>"
}
Error Returned from Microsoft:
"error": {
"code": "InvalidRequest",
"message": "Subscription validation request failed. Must respond with 200 OK to this request.",
"innerError": {
"request-id": "adf7fc7b-6b14-4422-8526-c1391be8dd27",
"date": "2017-08-07T16:24:59"
}
}
I understand everything to work as intended until my endpoint is sent the validation token because I receive the validation token but my endpoint rejects it because it is missing the client state.
Endpoint Log Snippet:
queryStringParameters": {
"validationToken": "<ValidationToken sent by Microsoft>"
}
I am basing my API endpoint logic off of some of Microsoft's developer guides. For the subscription creation in particular I am using this guide.
It appears this question was also asked but not answered on GitHub.
I represent Microsoft Graph Web hooks team ...
We verified your request in our MS Graph Service logs and confirmed that it was failed at Subscription validation phase because of HTTP status code='Unauthorized' from your endpoint ... Up to this everything is correct per your observation ...
By design, MS Graph Web hooks do not send the clientState header as part of the Subscription validation request. Please do not expect for this header during the subscription validation.
More information
You would have expected to receive the clientState as part of the validation request header because Office365 graph sends it https://msdn.microsoft.com/en-us/office/office365/api/notify-rest-operations. Office 365 Graph different from MS Graph ...
There are some document improvements observed with this question at https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/subscription_post_subscriptions ... Example Publisher Notification Payload, which is after successful subscription is mentioned together with the Subscription validation … We fixed those.
I think I have sort of the same problem as Microsoft Graph Subscriptions - Method not Allowed and the question is answered and there is this comment Microsoft Graph Subscriptions - Method not Allowed
Request https://graph.microsoft.com/v1.0/subscriptions
{
"changeType": "created,updated,deleted",
"notificationUrl":"https://c5e719ba.ngrok.io/api/ms/watch",
"resource": "me/events",
"expirationDateTime":"2016-12-07T02:23:45.9356913Z",
}
Response Header
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: application/json
Server: Microsoft-IIS/8.5
request-id: 9bd7a103-5ec0-4ed5-b20d-f8fb4cc75b88
client-request-id: 9bd7a103-5ec0-4ed5-b20d-f8fb4cc75b88
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"North Europe","Slice":"SliceA","ScaleUnit":"000","Host":"AGSFE_IN_4","ADSiteName":"DUB"}}
Duration: 261.5354
X-Powered-By: ASP.NET
Date: Tue, 06 Dec 2016 23:11:45 GMT
Response
{
"error": {
"code": "",
"message": "Exchange Online resources are not supported for MSA requests.",
"innerError": {
"request-id": "9bd7a103-5ec0-4ed5-b20d-f8fb4cc75b88",
"date": "2016-12-06T23:11:46"
}
}
}
But I'm not sure what should I do to make it work, I'm not using azure, but it seems that if I use Azure Active Directory B2C it should work, if this is what I really must do I think it's a hassle not being able to use all the microsoftgraph without using an azure service. (I can live without getting the profile photo This operation in version 1.0 supports only a user's work or school mailboxes and not personal mailboxes.).
I don't have an office365 account so I don't know if this won't be a problem if the user that uses my application sign in with an office 365 account.. because if it works with a home/commercial account I could verify if the account it's from MSA or home/commercial as a workaround I could do something like this https://github.com/microsoftgraph/msgraph-sdk-android/issues/26 and if I know that it's an MSA account I could ask the user to use another account in order to use the app...
So the question is: in order to make it work with a MSA (live) account do I've to use Azure Active Directory B2C?
Edit: Subscriptions for MSA (Live accounts) can now be created on the graph "beta" version for "me/messages" and "me/contacts".
We also support such MSA/live subscriptions for OneDrive resources like "me/drive/root".
Document endpoint
https://developer.uber.com/docs/ride-requests/references/api/v1-requests-request_id-receipt-get
My application already has FULL ACCESS for request_receipt
However, in my Rails application, when I request to endpoint API at: /v1/requests/my-request-id-here/receipt I receive the full message like this:
#<HTTParty::Response:0x7f8738f833f8 parsed_response={"message"=>"Forbidden", "code"=>"forbidden"}, #response=#<Net::HTTPForbidden 403 Forbidden readbody=true>, #headers={"server"=>["nginx"], "date"=>["Wed
, 02 Nov 2016 14:31:37 GMT"], "content-type"=>["application/json"], "content-length"=>["42"], "connection"=>["close"], "x-uber-app"=>["uberex-nonsandbox", "migrator-uberex-optimus"], "strict-transport-sec
urity"=>["max-age=0"], "x-content-type-options"=>["nosniff"], "x-xss-protection"=>["1; mode=block"]}>
Do you have any suggestion? The Uber API for developer is poor!
The issue is most likely you did not request the new scope when you authorized the user and got the access token. Access tokens are limited to the scopes approved by the user (so even though it is enabled in the dashboard) you need to pass the 'request_receipt' scope when authenticating the user.
See more details in the authentication guide: https://developer.uber.com/docs/ride-requests/guides/authentication/introduction#step-one-authorize
If you create a new access token with the scope all should work as expected.