I'm trying to use the PayPal Express sandbox (which I have to over 5+ years) and all of a sudden, I'm getting this error. I'm running the latest Chrome on a Windows 2012 server that's up to date. It's happening on the first call to PP using SetExpressCheckout. Where do I start looking for the cause?
After a week of trying to get help from PayPal support, I accidentally came across this link: https://www.paypal.com/webapps/mpp/ssl-security-update that let me to the fix. Support never mentioned it.
The key is to actively use TLS 1.2 in your code. It's not enough to just have your server hardened (we were showing an "A" rating on SSLlabs.com). I put the following immediately before the instantiation of WebClient:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
Connected to PayPal without a problem after that.
Related
As of yesterday, when I publish the (current) Product and its API, the deployed Assembly is not updated and what is running is from an earlier state - most likely from early December. The APIC domain was created at the end of Nov, so what I is deployed could even be the initial deployment.
As a test, I changed the API's description (add 'XXX') and changed a Gateway script to add XXX to a 'console.warn' at the start of the Assembly. The description change can be seen in Portal, but there is no 'XXX' visible in the DP log. I set DP log level to 'debug', but none of the 'tracing' statements added in Dec can be seen.
Does anyone have any ideas as to how I can resolve this? Or, how can I see the API's deployed code? I've looked in the DP File Management, but everything is dated at then end of Nov.
[EDIT]
Catalogs are in Dev mode, so I change and publish using same version. I have just done a series of tests using the api referred to above (VAT-Num-Check) (which is our first 'real' api) and an older trivial one that just divides two numbers. The Sandbox catalog is associated with the DEV gateway, and the SIT catalog, with the SIT gateway.
The other kind of corruption is, after deploying a new api, calling it results in 404 'No resources match requested URI'.
My conclusions are:
Something has broken in Mgmt server and/or DP APiC Gateway. Once code has been deployed to DP, it can't be changed or deleted. Changes in Portal are correct.
The possible exception is that the deployment of the VAT-Num-check API appears to have reverted to an earlier version after a CLI publish to the SIT Gateway this morning.
[/EDIT]
Background:
I have been creating a Windows script to publish draft Product/APIs and then run Postman tests. This means that I have been performing a lot of publish actions to DP (V5 type). On Monday evening, in my last run, the Postman tests all worked. Yesterday morning, some failed.
Back in early Dec, I made a change so that all JSON error messages in user responses used error as the 'prefix' to the message contents. Before that, some used message and some used reply. The reason for the failures is error messages have reverted to using the earlier 'prefix'.
API Connect 2018.3.7 went out of support on November 15, 2018. You'd need to upgrade to 2018.4.1.x, which will be supported for a longer term.
If you still have the issue at that point, then please open a support ticket for further investigation.
My app has been working fine since I changed my free account to a Pay-As-You-Go account but yesterday I started receiving the Access denied due to invalid subscription key error
I haven't changed anything. What can be the source of this error?
Microsoft CRIS servers were experiencing down time starting from ~ 10 pm GMT (according to my observation) on Wednesday 04/19 till 9 am GMT Thursday 14/20. I've experienced problems with log in, deployment access. But some of their servers went back and I was able to log in console. However all my deployments weren't accessible including newly created one. So, as their system went down, you might have problems accessing your deployment. Even if error description is related to invalid subscription key, it might be that issue. It's a new service and I still see 500 Internal errors in console often. If issue is still reproducing, I recommend you to contact their support team crservice#microsoft.com. They are very helpful. However they respond during European working hours.
I have experienced similar issues when we hit the API limits. It would not be a bad idea to check if either the number of requests per second or the volume has been reached ( in case of bootstrap keys it is 1000 hits)
I am using the authentication API as directed here: http://docs.microsofttranslator.com/oauth-token.html
Everything was working fine for about a week and suddenly today at around 11:55pm eastern time, all calls to get a new token give 500 errors with the following stack:
http://pastebin.com/uQ3VL6Am
We simply make a POST request to https://api.cognitive.microsoft.com/sts/v1.0/issueToken
with header 'Ocp-Apim-Subscription-Key' set to our key
I tried using our second API key, and it still does not work. I tried regenerating another key, and it still does not work. Our account manager says that the account should be in good standing.
Thank you
This issue has been resolved by Microsoft as of 6pm PST 1/30/17.
Got a tough one here.
So, we're trying to upgrade an OpenTok video chat application from Flash to WebRTC, and are running into socket errors as we try to implement the 'helloworld' WebRTC sample. The errors occur when we try to do a session.connect() call, not when we request a sessionId or a token. And the error basically looks like this (session_id and partner_id anonymized):
SessionInfo Response:
#document
<sessions>
<Session>
<session_id>asfgdagbasdfovnwoinvcwoinvoiandfvoinvoidnofgfdfgfgivniodfnv-sdfgdfgdfg-</session_id>
<partner_id>1234567890</partner_id>
<create_dt>Sun Sep 01 12:00:45 PDT 2013</create_dt>
<session_status>INFLIGHT</session_status>
<media_server_url>…</media_server_url>
<p2p_server_url>rtmfp://p2p101-oak.tokbox.com:1945/multicast</p2p_server_url>
<media_server_hostname>oms409-oak.tokbox.com</media_server_hostname>
<messaging_server_url>oms409-oak.tokbox.com</messaging_server_url>
</Session>
</sessions>
connectToMessenger
WebSocket error: undefined
TB.Socket Error :: The socket to oms409-oak.tokbox.com received an error: Unknown Error
TB.exception :: title: Connect Failed (1006) msg: TB.Socket Error :: The socket to oms409-oak.tokbox.com received an error: Unknown Error
Any ideas on what might be causing this? We're testing on the latest version of Chrome 29, and it happens in both localhost and on our production servers. So it doesn't seem to be a firewall. The one thing I can think of is that we're running on a Meteor/Node.js framework, which has websockets enabled by default. The code is pretty much boilerplate helloworld sample from the following:
http://tokbox.com/opentok/tutorials/hello-world/js/demo.html
We get the sessionId and token successfully, it's just that the session.connect() doesn't ever happen (and, thus, we can't ever get our connection object or subscribe to the event listeners).
Any ideas on how we might go about debugging this issue?
Thanks in advance for any help!
abigail
In typical fashion, after I spend two days on a bug, get so frustrated that I post a question to StackOverflow, and then figure it out an hour later.
Long story short, the OpenTok account had an 'enable WebRTC' option that wasn't set. It was an account administrator issue. Long story short... make sure devs have access to the accounts the business folks have!
I think you might be using the flash js library instead of the webrtc library. If you had joined your session using flash, it will not be able to work with webrtc.
Here's the webrtc library:
<script src='https://swww.tokbox.com/webrtc/v2.0/js/TB.min.js'></script>
Here is the flash library:
<script src='https://swww.tokbox.com/v1.1/js/TB.min.js'></script>
Think of webrtc and flash as two separate products, they do not interoperate.
I don't have any errors with my smart target application, but I do see in the event log, the following error messages:
ERROR 2012-09-19 14:30:09
com.tridion.smarttarget.utils.AmbientDataHelper - can't find defined
trigger-types in claim store (check if your smarttarget cartridge is
up and running)
and:
ERROR 2012-09-19 14:30:11
com.tridion.smarttarget.tags.TimeoutQueryRunner - The fredhopper query
timed out java.util.concurrent.TimeoutException at
java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source) at
java.util.concurrent.FutureTask.get(Unknown Source) at
com.tridion.smarttarget.tags.TimeoutQueryRunner.executeQuery(TimeoutQueryRunner.java:64)
ERROR 2012-09-19 14:30:11
com.tridion.smarttarget.tags.TimeoutQueryRunner - The fredhopper query
timed out
I would really like to understand what is causing these and how I can remove them. Or some suggested steps to help me debug this would be great :)
As I say, everything is working perfectly, later on in the logs I see the query to ST is correct and the results being generated.
In the event that is helps, I'm running on a 2009 implementation with Smart Target 2010, java 1.5.
thanks
John
Sounds like you might have a trigger configured in ST that does not actually exist in the ADF (or is mismatched). Have you looked through your trigger-types.xml file for anything obvious? Have you disabled an ADF cartridge but not removed the corresponding trigger in the XML perhaps? See the documentation for Defining trigger types.
I think your timeout is coming from the SmartTarget region rather than FredHopper. Sometimes a query that isn't already cached in FredHopper can take a while to return, even though it's ultimately successful. The ST query tag has a timeout (defined in the smarttarget_conf.xml file, or over-ridden with a tag attribute) that it will wait for a response from Fredhopper for before resorting to using the fallback content. This might explain why you see later in the logs that the query is correct and that results are returned. See the documentation for <tcdl:query>.
No conclusive answer for you I'm afraid, but I hope that helps.
The first error is logged if your SmartTarget cartridge is not running -- or if the data that it puts into ADF is lost somehow (e.g. you have disabled sessions in your web server).
In that case, SmartTarget will still do a query but it won't include anything from the Ambient Data Framework in it. If you don't have any triggers based on ambient data, the end result is the same for you.
To get rid of the error, make sure that smarttarget_cartridge is configured correctly.
As for the timeout error, it simply means that the query sent to Fredhopper took longer than the configured time. In that case it will show the fallback content instead. If this is happening a lot, you might want to increase the timeout within smarttarget_conf.xml.
I hope you found the issue, but for future reference, the first error message is raised when the claim "taf:claim:ambientdata:definedtriggertypes" is not set by the SmartTarget cartridge. This can be caused by:
SmartTarget cartridge could not load the the trigger types from the SmartTarget server. The log will show an error "can't retrieve list of defined trigger types from FH".
The HTTP session on your web server is expired during an active visit (the HTTP session expired but the browser is still open) and the claim is "lost".
The server does not support sessions like Peter mentioned.