Your jwt tools appear to be the fault

[Smart]

Problem:


developers.google.com/in-app-payments/docs/jwtdecoder
Your decoder decodes the JWT header as this:
{"alg":"HS256","typ":"JWT"}


https://checkout.google.com/customer/gadget/inapp/demo.html
But your encoder only encodes the JWT header as this:
{"alg":"HS256"}

Do you have a working method for creating encoded jwt?

[Ed Chavez]

The 2 are different demos/tool.

If you just base64url decode eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9 (the first section of the JWT) in the jwt decoder page, then you'll get"

{"alg": "HS256", "typ": "JWT"}

The "encoder demo" does in fact only provide the alg in the JWT header section, but I don't think its meant to be used "together with" the the decoder tool. In fact, you don't have a way to create/provide your own JWT header in this tool - it only works with the "body" (claim).

[Avanish]

Have a look at my gadget at http://inappstore.analyticsworkspace.com/, and click on JWT encoder once your are logged in. I have described how to encode JWT in code. Its pretty easy once you get some confidence.

Avanish

[Smart]

Avanish,

About your tool, I've done something very similar on my server.
I tried using your tool, I get error: 'invalid iss' message when I
test encoded jwt with your tool.

also I fail to see the use of this tool when you pre specify the
postback & buy urls.
the encoded jwt still fails when its used (error: we can't confirm
your purchases with the merchants server)!

Please explane.

On Feb 18, 12:55 pm, Avanish <avanish.bhar...@gmail.com> wrote:
> Have a look at my gadget athttp://inappstore.analyticsworkspace.com/, and

[Smart]

Avanish, also, How do you generate a signature?

On Feb 18, 12:55 pm, Avanish <avanish.bhar...@gmail.com> wrote:

> Have a look at my gadget athttp://inappstore.analyticsworkspace.com/, and

[Avanish]

Hi Smart,

Once you log into the Admin page, you will need to enter and save your Sandbox seller Identifier  (iss) and Seller secret values from your Google settings page. You can save the postback url i have specified back into the Google settings page.

Once you have done this, you can use the store url I have specified on item 1. You can paste your store url here and users may buy something from your url or you can give it to your test person to try it out.

If you have your own client side fully functioning but having difficulty seeing what Google post back to your server, you can keep my gadget's specified Postback URL saved into the Google settings page. In this way you can see Google is indeed posting something back to confirm. You can use the text in the gadgets server log for decoding with your own code. Once you are happy with your own server side you can go back to Google settings page and save your own postbackurl.

Let us know if you are stuck.

Cheers,

Aansih

[Avanish]

Have a look at this documentation http://self-issued.info/docs/draft-jones-json-web-token.html  ( see section 3.1 Example JWT ) and then my gadgets JWT Encoder. The signature is the result of bas64url of HMAC_SHA256 ( SigningInput , SellerSecret ) )

Avanish

[Smart]

I've used your tool to encode my jwt (just how you have said above)
then I went and integrated it with my buy buttons purchase() function.
At this point I click buy, but wallet is unable to confirm the order
with my server.

I don't see how the javascript 'jwt:foojwt' and the php
'$generated_jwt = JWT::encode($payload, $sellerSecret)' have anything
in common!?

function purchase(){
test=document.getElementById("test").value;
goog.payments.inapp.buy({
jwt:test,
success: function() { window.alert('success')},
failure: function() { window.alert('failure')}
})
}


I think this is ridiculous! I just wanted to simply integrate
following a full tutorial not learn about encoding/decoding (thats not
my job that's wallets job!).

No offence Avanish, I think your great for taking your time to help,
thank you so so much!! but you say you are the .net guy, Where the
hell is the .PHP guy? where the hell are the damn google wallet
support guys????


On Feb 19, 12:37 am, Avanish <avanish.bhar...@gmail.com> wrote:
> Have a look at this documentationhttp://self-issued.info/docs/draft-jones-json-web-token.html ( see section

[Ed Chavez]

Avanish is not the ".Net guy", I am....

People here are trying to help you. No offense - if you want to "just implement" and "not learn", then you may want to consider hiring Avanish to complete the integration for you....that way you can concentrate on your business (you can just plug and play).

If you're still up to it (learning):

Encoding/decoding (and signing) is your job, or rather your implementation's job. You have to properly do these functions to both send your data to Google and then properly verify on your end after Google's postback.

The "wallet's job" (Google's end) is verifying that "you" are the one sending the data (the JWT) for processing. If verified they process. If successful, they send data (JWT) to your server (the postback). For your own security, you have to verify - re: decode and verify that the data is actually valid/from Google.

# # # 

The (other) libraries linked in the dev docs are (based only on my read of the code - and I could be wrong) are only for JWT. You need to add your own code to make it work with In App Payments. In simple terms, In App Payments uses JWT - they are not the same thing. Google created In App Payments, Google did not create/nor control JWT spec. This is why in the other thread that I responded to, I provided a link to JWT spec.

I suggested the .Net library I wrote because I did get the sense that you wanted a somewhat "plug and play" solution. The .Net library I wrote goes a bit further - its really not (just) "for JWT", it is in fact for In App Payments (which uses JWT). BUT it will not save you from (still) writing code. You must write code to:

1. store the verified postback data (some database);
2. write code to verify against this stored data before displaying ok/granting access to whatever you are selling to the client's browser

Both are just database calls - so yes, the "job" of encoding/decoding/signing/verifying are all already done for you. You only have to add your business rules and a final server-side check.

As previously stated (in a separate thread). this only makes sense if .Net is a possible platform for you/your web site. Otherwise, you can disregard.

[Smart]

Wow your angry! I expect to use a full tutorial written by google not
a half written one where I am being sent to non-specific pages like:
http://self-issued.info/docs/draft-jones-json-web-token.html because
your team hasn't completed the necessary steps one must go through for
and I quote:

'Easily integrate with one API

There is just one API call to send and receive information to process
payment. It just takes a few lines of code.'
http://www.google.com/payments/payment-options/digital-goods.html

The reason that you have made this process very difficult to
do/'learn' is because you 'want be asked nicely' by nieve people to be
paid to do the integration therefor you are running a farse (with
intent), and practising false advertising again with intent!

PS: You still haven't answered my question... Where are the google
wallet support? If you are the support and you work for google you
should be thoroughly ashamed for exploding at a customer! If though on
the other hand you do not work for google Why do they guide us towards
you?

On Feb 19, 5:42 pm, Ed Chavez <edcha...@gmail.com> wrote:
> Avanish is not the ".Net guy", I am....
>
> People here are trying to help you. No offense - if you want to "just
> implement" and "not learn", then you may want to consider hiring Avanish to
> complete the integration for you....that way you can concentrate on your
> business (you can just plug and play).
>
> If you're still up to it (learning):
>
> Encoding/decoding (and signing) is your job, or rather
> your implementation's job. You have to properly do these functions to both
> send your data to Google and then properly verify on your end after
> Google's postback.
>
> The "wallet's job" (Google's end) is verifying that "you" are the one
> sending the data (the JWT) for processing. If verified they process. If
> successful, they send data (JWT) to your server (the postback). For your
> own security, you have to verify - re: decode and verify that the data is
> actually valid/from Google.
>
> # # #
>
> The (other) libraries linked in the dev docs are (based only on my read of
> the code - and I could be wrong) are only for JWT. You need to add your own
> code to make it work with In App Payments. In simple terms, In App Payments

> *uses* JWT - they are not the same thing. Google created In App Payments,

> Google did not create/nor control JWT spec. This is why in the other thread
> that I responded to, I provided a link to JWT spec.
>
> I suggested the .Net library I wrote because I did get the sense that you
> wanted a somewhat "plug and play" solution. The .Net library I wrote goes a
> bit further - its really not (just) "for JWT", it is in fact for In App
> Payments (which uses JWT). BUT it will not save you from (still) writing
> code. You must write code to:
>

>    1. store the verified postback data (some database);
>    2. write code to verify against this stored data before displaying

[Ed Chavez]

1. What you are referring to as "non-specific" is JWT. 
   
2. Its what In App Payments uses, and therefore is far from being "non specific" 
3. Your comments about encoding/decoding are described/explained in the JWT specification
   
4. You need to implement JWT to work with In App Payments
5. There are some code libraries that can help you with implementing JWT
6. You can write your own implementation of the JWT specification if none of them suit your needs

I've listed it all out trying to clarify things for you. Please refrain from colorful comments that have nothing to do with trying to solve your issue.

[Smart]

In tutorial in comparison to the Facebook credits tutorial for
implementation they leave nothing out, they don't send you away to
pages where there is no guidance they demonstrate the full process.
You must give us a full php tutorial in order for us to implement
google wallet.

On Feb 20, 4:30 pm, Ed Chavez <edcha...@gmail.com> wrote:
>    1. What you are referring to as "non-specific" is JWT.
>    2. Its what In App Payments uses, and therefore is far from being "non
>    specific"
>    3. Your comments about encoding/decoding are described/explained in the
>    JWT specification
>    4. You need to implement JWT to work with In App Payments
>    5. There are some code libraries that can help you with implementing JWT
>    6. You can write your own implementation of the JWT specification if

[Tim]

Agree. It would be really helpfull when there is more PHP
documentation or a tutorial available. Especially the part of writing
a script handling the post back data. See my post here:
https://developers.google.com/in-app-payments/forum/?place=topic%2Fin-app-payments%2FrFIMB3WeI3g%2Fdiscussion

[Smart]

So there are 2 of us now who both wan't a full php tutorial!

On Feb 21, 10:44 pm, Tim <t...@wordlayer.com> wrote:
> Agree. It would be really helpfull when there is more PHP
> documentation or a tutorial available. Especially the part of writing

> a script handling the post back data. See my post here:https://developers.google.com/in-app-payments/forum/?place=topic%2Fin...

[Karl Stubsjoen]

Ed, I feel your pain.  By the way, is that a beer you are tipping back in your profile pic?  

OK, but seriously.  I am writing a very lite-weight JsonWebToken generator in C# for my backend.  I think I have the steps correct:

1)  Encode the JWT Head to Base64

2)  Encode the JWT Payload to Base64

3)  Concat the 2 together with a . separator to create a JWS Secured Input value 

4)  Compute an HMAC256 hash with your seller key and this JWS Secured Input value

** done **

OK, in doing this I am not able to generate the resulting hash value they are coming up with.  I'm wondering if you were not able to replicate their samples.  Also, I get == characters on the tail end of my Encoded payload.  Did you too?  In the simple Joe sample, they don't have the == character on the end of this string.  So I don't understand that either.

Anyhow, any tips you can share?  Not much out there for examples.  I did find this post, which I think is quite helpful:

http://stackoverflow.com/questions/10055158/is-there-a-json-web-token-jwt-example-in-c

Thanks,

Karl..

[Matthew Endsley]

You do need to strip the base64 padding characters "=" from the header and claim before signing. You also need to strip the base64 padding from the signature as well.

Here's the production code we use for JWT creation in AirMech. While this is in Go instead of C# it shouldn't be too hard to follow/convert: https://github.com/mendsley/gojwt/blob/master/jwt.go

--
You received this message because you are subscribed to the Google Groups "In-App Payments for Web Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to in-app-paymen...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Karl Stubsjoen]

Mathew, thank you for your sample code, that was helpful.

OK, I have success, but only after an exhaustive disection of the expected results in bytes, encoded values, and using the base64 encoded value hack did I manage to get this sample to work.  

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#appendix-A.1

First, the authors of this sample should explain that there are hidden characters in their sample!!!! Each line in the json is terminated with a \r\n+ (where + represents a space).  Here are the 2 string values then I used for the Head and the Payload:

"{\"typ\":\"JWT\",\r\n \"alg\":\"HS256\"}";

"{\"iss\":\"joe\",\r\n \"exp\":1300819380,\r\n \"http://example.com/is_root\":true}";

I hope this helps anyone.  

Karl..