I've written the beginnings of a nodejs app to receive webhook notifications from travis-ci. What I'm stuck on is the inability to match my constructed sha2 hash of my combined username/repostory plus my Travis user token. The first piece comes along in the Travis-Repo-Slug header and the second piece is in my profile/info page at travis-ci.org. Here's what my code looks like:
var hash = crypto.createHash('sha256').update(repoSlug + userToken).digest('hex');
The value of hash does not equal the value I find in the Authorization header as I would expect it to be:
if (hash == req.get('Authorization')) {
// authorized request
I've been following the documentation here http://docs.travis-ci.com/user/notifications/ but perhaps in staring at this all day I've missed something obvious. Does anyone have suggestions on what may be going on?
Figured this out... I realized my travis access key wasn't the one currently configured in the github repo's webhook configuration. Travis uses this one as part of its hash when talking to my webhook. Hope someone finds this useful :)
Related
we're trying to add a new customerPaymentProfile for an existing customerProfile. we're patterning our code on the github sample provided
https://github.com/AuthorizeNet/sample-code-node/blob/master/CustomerProfiles/create-customer-payment-profile.js
the only difference is that, we don't pass CC details to our servers. instead, we pass opaqueData from frontend. on Initial customerProfile creation(with a single payment profile) it works w/c is good. but if we try to add a new paymentProfile(using a new opaqueData) we get the error code: E00114, Invalid OTS Token.
the official documentation regarding error code doesn't say much
And it seems like there's a few different cases, where it throws this error code
Using Accept.js
https://community.developer.authorize.net/t5/Integration-and-Testing/E00114-Invalid-OTS-Token/td-p/58879
https://community.developer.authorize.net/t5/Integration-and-Testing/E00114-Invalid-OTS-Token/td-p/59314
Our Case(node.js SDK)
https://community.developer.authorize.net/t5/Integration-and-Testing/Error-while-adding-new-paymentProfile-quot-code-quot-quot-E00114/td-p/69872
Others
https://community.developer.authorize.net/t5/Integration-and-Testing/Intermittent-Invalid-OTS-Token-Errors-E00114/td-p/57509
https://community.developer.authorize.net/t5/Integration-and-Testing/E00114-Invalid-OTS-Token-error-generates-while-creating-ARB/td-p/68685
We also tried to delay the transaction at least 7 seconds, before using the opaqueData maybe to allow their systems to sync as suggested here to receive the same error message.
Anyone ever encountered something like this before?
Any form of help would be highly appreciated.
We were doing something wrong, by doing trial and error(via API) to determine if a customer exists or not. hence hitting api once or twice resulting to an invalid token (error on 2nd call)
So we tried to create a customerProfile, w/ customerPaymentProfile & this will throw error if customerProfile already exist(if its a duplicate email). Whats good here, is that customerProfileId comes with the error payload.
We though of using customerProfileId from error payload, to create a new payment profile for the customer, giving us some edge by reducing one DB call on our system.
The issue with our strategy though, is that opaqueData will expire, when we use it to create customerProfile(w/ payment profile) even though the request failed.
So resolution is to save customer info in our system, and check if it's a returning customer or not. If it is, then get customerProfileId from db, and create new customerPaymentProfile on authorize.net
One could also create customerProfile first, w/o the customerPaymentProfile. if this transaction fails, then at least you haven't used the opaqueData yet and you get the customerProfileId w/o doing any query on your db. So when you try to create a new customerPaymentProfile, you won't get error code E00114 since opaqueData isn't used yet.
lessons learned the hard way for us, but hopefully it helps someone.
I am working with the Evernote Python SDK, and proceeding through the Oauth workflow description here.
http://dev.evernote.com/doc/articles/authentication.php
How do I get a oauth_token_secret? I have my consumer secret, but don't see how to get the oauth_token_secret.
To retrieve an access token, I believe I will need to use the "get_access_token" function. One of the required arguments there is the oauth_token_secret.
https://github.com/evernote/evernote-sdk-python/blob/master/lib/evernote/api/client.py
I have the other pieces required (oauth_token, oauth_verifier).
I think you can leave that blank.
https://discussion.evernote.com/topic/18710-access-token-secret-returning-blank/
I'm having trouble trying to send a POST message to an Azure SB Queue using PostMan.
The error I get is 401 40103: Invalid authorization token signature
My issue is generating the SAS as I'm trying to follow various articles and examples but I must be missing/overlooking/not understanding something.
If I describe what I've done, hopefully it'll become obvious where I'm making a mistake.
My Queue URL is https://GTRAzure.servicebus.windows.net/subscriptionpreference
My Policy is Submit
I've chosen an expiry date for December: 1512086400
My string-to-sign is https://gtrazure.servicebus.windows.net/subscriptionpreference\n1512086400 which is then encoded as https%3A%2F%2Fgtrazure.servicebus.windows.net%2Fsubscriptionpreference%5Cn1512086400
I then sign this using the Primary Key I get from the Submit policy. I'm using this to test: https://www.freeformatter.com/hmac-generator.html
This generates a code like 425d5ff8beb8da58e6f97e45462037e25ea56bcb63470f9b28761fa012f61090 using SHA-256 Which I then base-64 encode to get NDI1ZDVmZjhiZWI4ZGE1OGU2Zjk3ZTQ1NDYyMDM3ZTI1ZWE1NmJjYjYzNDcwZjliMjg3NjFmYTAxMmY2MTA5MA==
I then put it all together to get this which I place in the text of the Authorization header
SharedAccessSignature sig=NDI1ZDVmZjhiZWI4ZGE1OGU2Zjk3ZTQ1NDYyMDM3ZTI1ZWE1NmJjYjYzNDcwZjliMjg3NjFmYTAxMmY2MTA5MA==&se=1512086400&skn=Submit=&sr=https%3A%2F%2Fgtrazure.servicebus.windows.net%2Fsubscriptionpreference%5Cn1512086400
I think the string to sign which you are providing is incorrect because \n is not getting treated as new line which generates encoded value as :
https%3A%2F%2Fgtrazure.servicebus.windows.net%2Fsubscriptionpreference%5Cn1512086400
which gives Authorization failure.
But if it is treated as new line, it will give value like this:
https%3A%2F%2Fgtrazure.servicebus.windows.net%2Fsubscriptionpreference%0A1512086400
which will not give error.
I'm generating a token on our auth server (Node.js) in node-jsonwebtoken that will be passed to an API (PHP Laravel) and verified by tymondesigns/jwt-auth.
A token generated by tymondesigns/jwt-auth will be verified successfully by
its own verify function, node-jsonwebtoken and jwt.io.
A token generated by node-jsonwebtoken will be verified successfully by its own verify function, jwt.io, but not tymondesigns/jwt-auth.
On the Laravel server, i get the following error when I try to verify a token generated by node-jsonwebtoken:
TokenInvalidException in NamshiAdapter.php line 71:
Token Signature could not be verified.
The payloads look identical when I look at them over at jwt.io. I have even tried to generate the exact same token on the Node server by passing the same iat,sub,iss,exp,nbf and jti as generated by a working token, but tymondesigns/jwt-auth still won't accept it.
Is there anything else that could be causing this, but isn't visible in the decoded information? I'm also not 100% sure how jti works. Maybe there is something preventing this from working about that?
node-jsonwebtoken (7.1.9), tymon/jwt-auth (0.5.9), namshi/jose (5.0.2)
The last version of the namshi/jose library is 7.0.
There is also a known bugs for all ESxxx algorithms.
If you cannot verify signatures using that library, you could try with another one.
I developed a library that supports all features described in the RFCs related to the JWT, including encryption support.
The reason is, as mentioned by Spomky aswell, a bug in namshi/jose related to the iss claim. It is resolved in 7.0 which is used by tymon/jwt-auth 1.0.0-alpha.2. However, since there currently isn't a documented way to install 1.0.0-alpha.2, we probably have to wait for a stable release.
Until then, since the problem and the bug is related to the iss claim, removing the iss requirement from required_claims and generating the tokens without it solves the problem temporarily.
In my case I had a url inside the payload. PHP escapes slashes by default when encoding to JSON, while Node.js doesn't. When the verification JWT gets generated in PHP (with those extra backslashes) of course the final hashes won't match since the payload is just different. Solution is to use the JSON_UNESCAPED_SLASHES flag when converting to JSON inside your JWT library, I was using https://github.com/namshi/jose so I created a simple class like this one:
use Namshi\JOSE\SimpleJWS;
class SimpleJWSWithEncodeOptions extends SimpleJWS
{
protected static $encodeOptions = 0;
public static function setEncodeOptions($options)
{
self::$encodeOptions = $options;
}
/**
* Generates the signed input for the current JWT.
*
* #return string
*/
public function generateSigninInput()
{
$base64payload = $this->encoder->encode(json_encode($this->getPayload(), self::$encodeOptions));
$base64header = $this->encoder->encode(json_encode($this->getHeader(), self::$encodeOptions));
return sprintf("%s.%s", $base64header, $base64payload);
}
}
Then it could be used like:
SimpleJWSWithEncodeOptions::setEncodeOptions(JSON_UNESCAPED_SLASHES);
$jws = SimpleJWSWithEncodeOptions::load($token);
$jws->verify($key);
$data = $jws->getPayload();
This problem was very specific to my payload content but it could help someone
I am trying to make a simple REST call to the Set Blob Properties API (http://msdn.microsoft.com/en-us/library/windowsazure/hh452235) to just turn off/on logging. I have gotten the REST API call to successfully work for retrieving Blob Properties, so I know my hashing algorithms, headers-setting, and Authentication signature creation works, but I can't seem to get it working on the Set Properties side of things. I keep getting an error on the Authentication Header, so I know I'm not doing something right there.
I have copied below what is being created and eventually hashed and put into the auth header string. The online documentation (http://msdn.microsoft.com/en-us/library/windowsazure/dd179428) does not really help in determining which of these fields are absolutely required for this particular type of Blob request, so I've tried filling most of them in, but I don't seem to get a difference response regardless of what I fill in. I've also tried the Shared Key Lite authentication, which would be preferred since it's much more lightweight, but that doesn't seem to work either when I fill in all 5 of those fields.
Shared Key Authentication for Blob Services:
PUT\n
\n
\n
130\n
(MD5_CONTENT_HASH)
\n
\n
\n
\n
\n
\n
\n
x-ms-date:Tue, 19 Jun 2012 19:53:58 GMT\n
x-ms-version:2009-09-19\n
/(MY_ACCOUNT)/\n
comp:properties\n
restype:service
Is there anything obvious I'm missing here? The values (MD5_CONTENT_HASH) and (MY_ACCOUNT) are of course filled in when I make the request call, and the similar request call to "GET" the properties works fine when I send it. The only difference between that one and this is that I'm sending the MD5_content, along with the content-length. I may be missing something obvious here, though.
Any advice would be greatly appreciated! Thanks in advance.
-Vincent
EDIT MORE INFO:
Programming Language I'm using: Objective-C (iOS iPhone)
I'm also using ASIHTTPRequest to make the request. I simply define the request, setRequestMethod:#"PUT", then I create the request body and convert it to NSData to calculate the length. I attach the request-body data via the appendPostData method to the request. I then build the auth string above, hash the whole thing, and attach it to the request as a header called "Authorization".
Request Body String I'm using:
<?xml version=\"1.0\" encoding=\"utf-8\"?><StorageServiceProperties><Logging><Version>1</Version></Logging></StorageServiceProperties>
I know this is an incomplete request body, but I was planning on waiting for it to give a failure on "missing request body element" or something similar, until I proceeded on creating the full XML there. (could that be my issue?)
Error I get from the server:
<?xml version="1.0" encoding="utf-8"?><Error><Code>AuthenticationFailed</Code><Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:accc4fac-2701-409c-b1a7-b3a528ce7e8a
Time:2012-06-20T14:36:50.5313236Z</Message><AuthenticationErrorDetail>The MAC signature found in the HTTP request '(MY_HASH)' is not the same as any computed signature. Server used following string to sign: 'POST
130
x-ms-date:Wed, 20 Jun 2012 14:36:50 GMT
x-ms-version:2009-09-19
/(MY_ACCOUNT)/
comp:properties
restype:service'.</AuthenticationErrorDetail></Error>
What's odd is that the error I get back from the server seems to look like that, no matter how many parameters I pass into the Authentication signature.
Thanks for any help you can offer!
Comparing your signed string and the error message indicates that you're sending a POST request but signing as though you're sending a PUT.