Good Morning (morning in Oregon). I am going through the Intuit Developer Testing process and continue to get errors when attempting to render the PayPage with ticket and opid strings that were provided to me in the previous step. To prevent links in this message, I separated the https:// from the remainder of the url.
Using:
Firefox browser (internet explorer for intuit is under construction?)
Windows XP Professional version 2002 service pack 3
ORIGINAL DATA FROM PREVIOUS STEP AND VARIABLE URL FOR RENDER PAYPAGE STEP:
Ticket=JiRr77+9RA7vv73vv70JdVcrYWnvv71b77+977+977+9Cu+/vW7vv70a13061215442877+9DhprATIXA++/ve+/vXfvv73vv73vv73doO+/vXDvv70nHWTvv73v
OpId=77-977-9VO--vX130612154428Dvv73vv70ZHyo7
PTC url with variables: (https://) paymentservices.ptcfe.intuit.com/checkout/terminal?Ticket=(X)&OpId=(Y)&action=checkout
When I DO NOT encode the url, I get the Secure Payment Processing window with the following message: Transaction Not Processed - Our system is currently facing some intermittent problems. Please try again in few minutes.
Unencoded url used:
(https://) paymentservices.ptcfe.intuit.com/checkout/terminal?Ticket=JiRr77+9RA7vv73vv70JdVcrYWnvv71b77+977+977+9Cu+/vW7vv70a13061215442877+9DhprATIXA++/ve+/vXfvv73vv73vv73doO+/vXDvv70nHWTvv73v&OpId=77-977-9VO--vX130612154428Dvv73vv70ZHyo7&action=checkout
When I encode the ticket portion of the url only and then paste the results into the url, I get the Transaction not processed screen again.
Resulting url w/ encoding of ticket only:
(https://) paymentservices.ptcfe.intuit.com/checkout/terminal?Ticket=JiRr77%2B9RA7vv73vv70JdVcrYWnvv71b77%2B977%2B977%2B9Cu%2B%2FvW7vv70a13061215442877%2B9DhprATIXA%2B%2B%2Fve%2B%2FvXfvv73vv73vv73doO%2B%2FvXDvv70nHWTvv73v&OpId=77-977-9VO--vX130612154428Dvv73vv70ZHyo7&action=checkout
When I encode the entire original url I get the QBMS Error Page and [Intuit Logo] - Not Found - Error Code 404
Encoded url entire resulting url encoded:
(https://) paymentservices.ptcfe.intuit.com/checkout/terminal%3FTicket%3DJiRr77%2B9RA7vv73vv70JdVcrYWnvv71b77%2B977%2B977%2B9Cu%2B%2FvW7vv70a13061215442877%2B9DhprATIXA%2B%2B%2Fve%2B%2FvXfvv73vv73vv73doO%2B%2FvXDvv70nHWTvv73v%26OpId%3D77-977-9VO--vX130612154428Dvv73vv70ZHyo7%26action%3Dcheckout
I feel I have tried everything and I do not know what else to try. I am under a deadline to get this done. I tried everything suggested in the one thread I found where this issue was discussed. But I noted there was never really an answer on that thread. I hope you can help me out. :)
I just had this problem, and found the cause. They want the value for Ticket and OpId url encoded. In most scripting languages like PHP, that will turn spaces into "+" symbols. They then expect those plus symbols to also be url encoded. So, in PHP if you do something like this to the Ticket and OpId and any other parameters you pass it will fix the problem (this assumes $ticket and $op_id are already set):
$ticket = str_replace('+','%2B',urlencode($ticket));
$op_id = str_replace('+','%2B',urlencode($op_id));
Related
I was creating an API for TD Ameritrade (my first time creating or dealing with APIs) and I needed to put in my own call back URL. I know that callback URL is where the API sends information to and i heard that I can just use my localhost API. I scoured the internet and I dont know how that would work and I was wondering if i can just use http://localhost?
Sorry if I seem like a noob because I am
In short, yes.
Follow the excellent directions at
https://www.reddit.com/r/algotrading/comments/c81vzq/td_ameritrade_api_access_2019_guide/. (Even with them, I spent excessive time on trial and error!)
Since stackoverflow has a limit of 8 links in a response, and the localhost text string looks like a link, I’m showing it with the colon replaced by a semicolon, i.e., http;//localhost to reduce the link count. Sorry.
I used the Chrome browser after first trying Brave, which did not work for, possibly because of my option selections.
Go to https://developer.tdameritrade.com/user/me/apps
Add a new app using http;//localhost (delete existing app if there is one).
Copy the resulting consumer key text string (AKA client_id or OAuth User ID).
Go to https://developer.tdameritrade.com/content/simple-auth-local-apps, follow instructions. Note: leading/trailing blanks were inserted by MSWord due to copy/paste of the auth code, which had to be manually deleted after wasting excessive time identifying the problem. The address string looks like:
https://auth.tdameritrade.com/auth?response_type=code&redirect_uri=http%3A%2F%2Flocalhost&client_id=ConsumerKeyTextString%40AMER.OAUTHAP
This returns a page stating the server refused to connect, but the address bar now contains a VeryLongStringOfCharacters in the address bar:
https;//localhost/?code= VeryLongStringOfCharacters
Copy the contents of the address bar, go to https://www.urldecoder.org/, decode the above, and extract the text after “code=”. This is your refresh_token
Go to: https://developer.tdameritrade.com/authentication/apis/post/token-0, fill out the fields with
grant_type=authorization_code
refresh_token=<<blank>>
access_type=offline
code=RefreshTokenTextString
client_id=ConsumerKeyTextString#AMER.OAUTHAP
redirect_uri=http://localhost
Press SEND.
If the resulting page starts with HTTP/1.1 200 OK, you have succeeded.
Try updating your redirect to:
redirect_uri=https://localhost
They may require https now and you need a colon instead of a semicolon. Everything looks correct. This process generally takes me more then one attempt, and 15 minutes to an hour to get my refresh token squared away every 90 days.
dont use #AMER.OAUTHAP in client_id
If you generate a new code and based on that try to get a new access token. it should work.
Background: I'm trying to log into an HTTPS site with my valid credentials, navigate to a page that has a frequently updated list, and then scrape the list.
I was using code someone else wrote, which worked until a few weeks ago. I am new to this, but even i can see that the code was not very good, so i am trying to rewrite.
First I log into the site and create an tunnel. Then I move to the page where my list is and grab the list, etc.
Here's what's weird. The login fails every time, until I turn on Fiddler. With Fiddler running it succeeds every time.
Any idea about why this would happen and how to fix?
Many thanks.
I got it working!
For anyone who finds themselves in the same situation (I've seen a number of posting of similar questions - but the answers hadn't worked for me, so I expect I am not alone), I eventually saw that I needed to set the security protocol to TLS. The specific syntax I used was:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
The setting needs to be specified before the Httpwebrequest get or post event occurs.
If you have a similar problem, I hope this helps.
I had an invalid "User-Agent" header. It contained invalid characters (ä, ö, ü).
Background
In our Apache configuration we use mod-auth-external (previously on Google Code) to invoke PAM authentication.
Now there is a request for proper handling of shadow-based password expiration:
If password is before warning period Apache should respond with HTTP status code 200. Nothing new here.
If password is in warning period (its validity end is near) Apache should respond with HTTP status code 200, but include somehow information about the warning period.
If password is in expiration period (it is no longer valid but user can still change it on his own) Apache should respond with HTTP status code 401 and include somehow information about expiration period.
If password is beyond expiration period (it is no longer valid and account was locked, administrator must unlock it) Apache should respond with HTTP status code 401 and include somehow information about the locked state.
(There are also corner cases of page missing or some other errors. It is not clear what to do then. But it seems that solving above points would allow to solve those corner cases as well.)
Our PAM authenticator (used through mod-auth-external) is able to differentiate those cases by adjusting return values. That we already have.
The problem is however how to get information from the authenticator to the associated action serving the page (either actual page with 200 status code or 401 error document).
Current investigations
It should be noted that there is significant difference between requirement 2 and requirements 3 and 4.
Requirements 3 and 4 alone are somewhat easier because they both involve our mod-auth-external authenticator returning error (access denied). So we only need to know how to get that error code in 401 error page. I even raised issue on that on mod-auth-external page.
Requirement 2 is much more difficult. In that case our authenticator must return 0 (access granted) and still somehow propagate information about the warning to whatever gets served in the end.
Logs parsing
Obvious (and ugly) idea is to parse logs. mod-auth-external description on Google Code Wiki mentions that authenticator return value gets written to Apache syslog. Also whatever authenticator prints to standard error stream gets logged as well.
This could be used to pass information from authenticator to some other entities.
The difficulty here is that it is not clear how to do it safely. What to print to be sure that "the other entity" will match properly current request with log entry. Mere URL doesn't seem to be enough since there can be multiple requests for the same URL at the same time. While I don't see anything more useful in what authenticator gets.
Another issue here is that it seems that to be able to parse the logs you have to have some non-trivial code running for "the other entity". And this complicates things further since how should we do it?
Another idea
If we could make the authenticator somehow modify "request session" (or whatever, maybe just environment? - I don't know, I'm new to Apache) to add arbitrary data to it we would be (almost) at home.
Our authenticator would somehow store "password status" and also possibly days remaining to the end of warning/expiration period (if applicable). Then upon serving 401 error page we would retrieve that back and use it to dynamically generate content of the page.
Or even better we would have it stored in session so that the other end could read that data directly. (For cases where it is not simply a browser showing page.)
But so far I fail to see how to do that.
Do you have any idea how to meet those requirements?
For over a month I got no answer here. Nor on GitHub issue that I opened for mod-auth-external.
So I ended doing a custom modification to our mod-auth-external. I don't like modifying third party software but this one seems dead anyway. And also it turned out we are using pretty old version (2.2.9 which I upgraded to 2.2.11, the last in 2.2.x line). Which already had some customizations anyway.
I explained details of the solution in a comment to my GitHub issue so I will not repeat them here.
I will however comment on shadow details as they were not mentioned there.
I had two choices: either use getspnam function to retrieve shadow data or to parse messages generated by PAM. First attempts based on getspnam function but in the end I used PAM messages. I didn't have strong reasons for any of those. However I decided to propagate in HTTP response not only shadow status but any PAM message that was generated and so it seemed easier to follow that way.
I have a page tab app that I am hosting. I have both http and https supported. While I receive a signed_request package as expected, after I decode it does not contain page information. That data is simply missing.
I verified that like schemes are being used (https) among facebook, my hosted site and even the 'go between'-- facebook's static page handler.
Also created a new application with page tab support but got the same results-- simply no page information in the signed_request.
Any other causes people can think of?
I add the app to the page tab using this link:
https://www.facebook.com/dialog/pagetab?app_id=176236832519816&next=https://www.intelligantt.com/Facebook/application.html
Here is the page tab I am using (Note: requires permissions):
https://www.facebook.com/pages/School-Auction-Test-2/154869721351873?id=154869721351873&sk=app_176236832519816
Here is the decoded signed_request I am receiving:
{"algorithm":"HMAC-SHA256","code":!REMOVED!,"issued_at":1369384264,"user_id":"1218470256"}
5/25 Update - I thought maybe the canvas app urls didn't match the page tab urls so I spent several hours going through scenarios where they both had a trailing slash or not. Where they both had a trailing ? or not, with query parameters or not.
I also tried changing the 'next' value when creating the page tab to the canvas app url and the page tab url.
No success on either count.
I did read where because I'm seeing the 'code' value in the signed_request it means Facebook either couldn't match my urls or that I'm capturing the second request. However, I given all the URL permutations I went through I believe the urls match. I also subscribed to the 'auth.authResponseChange' which should give me the very first authResponse that should contain the signed_request with page.id in it (but doesn't).
If I had any reputation, I'd add a bounty to this.
Thanks.
I've just spent ~5 hours on this exact same problem and posted a prior answer that was incorrect. Here's the deal:
As you pointed out, signed_request appears to be missing the page data if your tab is implemented in pure javascript as a static html page (with *.htm extension).
I repeated the exact same test, on the exact same page, but wrapped my html page (including js) within a Perl script (with *.cgi extension)... and voila, signed_request has the page info.
Although confusing (and should be better documented as a design choice by Facebook), this may make some sense because it would be impossible to validate the signed_request wholly within Javascript without placing your secretkey within the scope (and therefore revealing it to a potential hacker).
It would be much easier with the PHP SDK, but if you just want to use JavaScript, maybe this will help:
Facebook Registration - Reading the data/signed request with Javascript
Also, you may want to check out this: https://github.com/diulama/js-facebook-signed-request
simply you can't get the full params with the javascript signed_request, use the php sdk to get the full signed_request . and record the values you need into javascript variabls ...
with the php sdk after instanciation ... use the facebook object as following.
$signed_request = $facebook->getSignedRequest();
var_dump($signed_request) ;
this is just to debug but u'll see that the printed array will contain many values that u won't get with js sdk for security reasons.
hope that helped better anyone who would need it, cz it seems this issue takes at the min 3 hours for everyone who runs into.
We have a few sites that run on different CMS (Drupal, Joomla etc.). We would like these sites to share a phpbb forum (on a different domain) and for people that register on each site to have a user account automatically created on the forum as well.
For that I have writen a script that sends a php curl request that mimics phpbb's registration process.
First, I tired a simple sign up form and it worked well. But since the forum uses Captcha I needed to add a form to my script so the user could input the Captcha string. And here things did not pan out so well. After many hours of examining the phpbb code files I managed to more or less put my finger on where the problem occurs, although my limited phhbb knowledge prevents me from finding a solution so I thought I would ask for help here.
My script sends a curl request to ucp.php?mode=register to get past the "agree to terms" screen, parses the result to get the tokens and creation time and then sends another request. The returned value is the registration screen with the Captcha image. Except no image can be seen as the url to the image script is relative and so I alter the output result and make the url an absolute url.
So instead of
./ucp.php?mode=confirm&confirm_id=xxxxxxxxxxxxx&type=1
I alter the code to
http://www.mydomain.com/phpbb3/ucp.php?mode=confirm&confirm_id=xxxxxxxxxxxxx&type=1
And get a Captcha image (xxxxxxxxxxxxx is the confirm_id string that changes every time).
And this is where I hit a brick wall. The image generated is never the correct captcha string.
If I var_dump the $captcha variable in ucp_register.php I can see the correct string which is never the one in the Captcha image. I placed bits of code in the phpbb files that output certain variables to help me understand what's going on behind the scenes. Here is what I managed to gather, hoping some one could tell me why it's happening or at least point me in the right direction:
In captcha_abstract.php and captcha_gd.php the is the variable $this->confirm_code. When I dump this into a file in both cases I can see the right captcha code (same as when I output the $captcha var in ucp_register.php).
In ucp_confirm.php there is the $captcha->code var which turns out holds the string that I see when I output the Captcha image.
When I just go through the registration process normally through the browser $this->confirm_code and $captcha->code holds the same value.
So it's obvious that changing the ucp.php?mode=confirm line above is causing this, yet I can not avoid that as if I don't do it I don't get a Captcha Image.