I've been told that Sagepay protocol 2.x is being deprecated and to upgrade to v3
Taken a look at the source code, but it's not obvious which one it uses, could anyone enlighten me on this?
It uses protocol v3.0 as of February 2015 (github/packagist theleague/omnipay-sagepay v2.2.0).
SagePay is due to remove their V2.3 protocol API completely in July 2015. Hopefully that won't catch out too many people when it happens.
The v3.0 protocol does not support the simulator mode, and the OmniPay driver reflects that. I hear rumours that support for the simulator may be brought back later 2015. If so, I'll get support added back into the driver as quickly as I can.
Update: just to clarify, there is still a test mode, so you can test against your SagePay test account. It is the simulator mode that never made it to the V3.0 protocol. You can still test without that, and it's fine for shops to do so. The simulator was much more useful to gateway interface developers rather than integrators, so users of OmniPay/SagePay should not really miss out.
Related
I am using sdk v4 bot embedded in sharepoint 2016 page using iframe webchat https://webchat.botframework.com/embed/[Token] url. It stopped working in IE 10. I remember it worked before 3 weeks. Please help as we put the bot in production.
There was a recent update to webchat, so I'm guessing this is a webchat version issue. Do you have the ability to use directline channel with botframework-webchat instead? There are a number of samples. In the getting-started full-bundle sample, you can see where the latest version is specified. You can use this to specify a later version, though I'm not sure if it will let you go far enough back.
You are also going to need to customize the formatting, as the new webchat comes through with essentially no formatting. There are a number of samples on that site showing the different formatting options as well.
For shorter term fix, you may be able to request your specific bot app ID to be reverted by contacting the Microsoft contact from this github issue, though I would recommend also working on updating your implementation as that probably won't be available forever.
I'm currently having a lot of trouble with the google API support team and was wondering if anyone had figured out their process. I'm developing an extension that uses identity.launchWebAuthFlow() to authenticate with google for google drive access. Since July 2017, google has started requiring "Verification" for oauth. As I don't own my extension's domain {random}.extensions.allizom.org, I have no idea how to pass their verification requirements.
You can read about that process here: https://developers.google.com/apps-script/guides/client-verification
They've rejected me once saying my client id is deleted or invalid or does not need verification - I verified that the client exists, is still servicing requests, and still produces the unverified warning screen detailed in the link above.
When I reached out specifically to webstore support, the response said:
Dear Brandon,
Thank you for contacting Chrome Web Store Developer Support! I understand that you're having an issue regarding developing a web extension for both Chrome and Firefox using Google Drive API. As much as I'd love to assist you, unfortunately, our team cannot offer much support on this matter. My best advice is to ask the community on Stackoverflow, or create a bug report directly to the Chrome Browser/Extension experts using the Chromium Public Issue Tracker. The engineers are actively working on the reported problems on this list, so I'm sure that you'll be able to get the information that you're looking for.
I appreciate your understanding and cooperation. Please let me know if there's anything else I can do for you, I'm happy to assist. :)
Warm Regards,
[Redacted]
Chrome Web Store Developer Support
Again the major problem here is that I cannot prove ownership of the identity.getRedirectUri() for my extension as the requirements state. I know other addons use google APIs, but I don't know if this verification process is a way to ban firefox developers from the google api ecosystem.
As a bit of question justification, I can find no documentation anywhere from July 18 2017 or later where developers have run into this, and I think this question will provide significant value to any Firefox addon developers who seek to use any of Google's APIs.
I have seen that yesterday Web API RTM has been released by Microsoft.
However I can't seem to find any log about what has changed from RC to RTM and any tips on what has changed.
We have a service that's ready for production next week, and I am not sure whether to roll with RC or upgrade to RTM this late in the project. What value does it add?
Thanks
Ubal
The official release notes can be found here at www.asp.net.
As #Aliostad kindly mentioned, I wrote an overview post highlighting what's changing and including some code samples and other references.
Henrik also wrote a nice overview post - and that one's also focused on the preview for the out-of-band functionalities available as NuGet packages (OData, tracing, Help page, and a formatting library for Win8).
If you ask whether you should upgrade - obviously yes. There aren't many breaking changes so it should be rather painless, and you get a mature, production-deployable product. It's well worth it imho.
The question's pretty straightforward and the old topic is here. I'm hoping to get up-to-date answers since IE9's gonna be released this March 14, 2011.
In addition, I would also like to ask when will Firefox and Opera be supporting WebSockets?
I've been following both the development of IE9 and I also participate in the HyBi WG (WebSockets protocol). Microsoft has been keeping the demo implementation of WebSockets up to date with the latest revisions of the protocol, however, I suspect that the initial release of IE9 will not have built-in WebSockets support. It will probably not be until IE10 unless they start to see it as a big competitive disadvantage in which case we will likely see it added in a IE9 update before IE10.
Firefox will likely support WebSockets in an update to FF4 or with FF5 (but the plan is that 5 will come out this year). Also, you can turn on the current implementation in FF4 using a about:config option.
I have no idea about Opera. They are interesting in the protocol but they've been pretty silent on the HyBi list.
Also, if you need WebSockets right now you can always use the Flash shim/fallback web-socket-js.
Update:
I forgot, Opera 11.00 does have WebSockets support built-in but disabled. Go to opera:config and search for WebSocket.
So in summary, just about every modern browser has WebSockets support in some way either built-in and enabled (Chrome, Safari, iOS), built-in but disabled (FF4 and Opera), as a downloadable add-on (IE9), or using the web-socket-js Flash emulator (everything except iOS).
Nope, The RTW version of IE9 does NOT support a websocket type... :(
UPDATE: The IE team is developing websockets for their browser, but it's not included in the initial release because the standard is in a fluid state. Although the implementation is stable, the standard isn't. If you want to test it out in IE9, you can by downloading it here:
http://html5labs.interoperabilitybridges.com/
You can hear more about it by listening to this DotNetRocks podcast:
http://www.dotnetrocks.com/default.aspx?showNum=648
Best regards.
IE9 does support WebSockets but not as a "built-in" functionality. You have to download it as a plugin from http://html5labs.interoperabilitybridges.com
The reason given by microsoft for not including in default setup is - the standard is unstable and keeps changing and in default setup only stable HTML5 standards shall be included.
So in a way IE10 as of now will also not include.
The HTML5Labs site will provide "experimental" support to unstable standards.
How do I let Microsoft know about a problem I've found in one of their core library routines? Do they have a central repository to report these things?
I am not a member of Microsoft Development Network (MSDN).
Or should I even bother?
There is no official way to report bugs to Microsoft for an end-user. If you are participating in a beta program for an upcoming release, the beta program includes a bug-reporting channel. Otherwise, if the bug causes problems that you want to get resolved, you can call Microsoft support, and they will help you solving the problem (be it by providing a patch, or a work-around); if the problem turns out to be caused by a bug indeed, they will refund the costs of the support call.
Microsoft does have a central repository (perhaps separate ones per product), but this repository is not accessible for the general public.
If it's a documentation bug (or if the documentation should call it out), you can get good results with the Feedback links in MSDN library. You can report bugs in Microsoft developer tools (among other things) by signing up at connect.microsoft.com.
If you're sure you've found a bug in a core library routine, you can raise a PSS (support case. It'll cost you money, but if it turns out you're right (and they issue you a hotfix), I think that they refund the money.
I've never been so confident that I've found a bug that I'm willing to make that gamble.
I don't know why ChrisN took back his answer. I saw it earlier today when he had it up, He said:
You can report bugs on the Microsoft Connect website (I've done this in the
past). You don't have to have an MSDN
subscription.
I had not heard of the Microsoft Connect website, but when I used the search box there to search for "Registry Unicode", the first entry listed was a bug very similar to the one I encountered. And clicking through on that entry led me to look at the conversation that appears to be Microsoft people addressing the issue, passing it on to appropriate people and escalating it as necessary.
I have no experience with the Microsoft Connect website, but if it turns out to be as promising as it appears, this may be the answer to my question.