What is the road map for support on the APNS Legacy and enhanced binary interface? (When will it no longer work?) I am currently using PushSharp which appears to use the enhanced binary interface, but does not support the newest interface.
ref: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/LegacyNotificationFormat.html
PushSharp 3.x release support the new enhanced binary interface, and in addition, http/2 provider api support is being actively developed. PushSharp 2.x will be deprecated.
Related
I'm making an HTTPS call over TLS 1.2 with client certificates to another company using .Net Framework 4.8 and the handshake fails after the client certificate is sent. Their company support claims .Net framework does not support SNI using this page as reference https://www.ssls.com/knowledgebase/what-is-sni-technology/. However my network capture indicates it does, since it includes the "server_name" extension in the client hello..Net framework call with SNI extension The same call can be made successfully using python so there is evidence they are correct, but I can't find any definitive answer online regarding .Net Framework. How can we determine if the issue is their network or lack of support in our framework?
Edit: This website indicates there is support since 4.5 https://developer.awhere.com/api/server-name-indication-sni-support-requirements
.NET Framework don't care about SNI support, because .NET has no knowledge of it. Network operations in .NET Framewrok are built around a network stack and low-level API provided by operating system. If you were able to install .NET 4.8, then you are running your app on a modern client that certainly supports SNI. This means that the issue is elsewhere, but not in .NET Framework.
I can't find any definitive answer online regarding .Net Framework
and you won't find for reasons explained above.
The simple answer is no, it does NOT, not in NetStandard 2.0 either.
But it does with netcore-5+.
Prior to that, while it supported client connections, it did not support customized selecting of the TLS-certificate based on SNI prior to netcore-5.
You could do it prior to that with the StreamsExtended library, though.
However, that's not part of the official .NET Framework, but a 3rd party library.
So no, the full .NET framework does not support that at all.
We're using AWS SDK .NET for getting files from AWS S3 storage. When the application was implemented a few years ago, the AWS was only supporting TLS 1.0. Now hopefully it's supporting TLS 1.2. I'd like to know which version and where I can download the library/packages. What's the minimum requirements for the .NET Framework? We're using the AmazonS3Client to handle the underlining connection to the S3 storage account.
Found the correct version that will be supporting the TLS 1.2.
https://aws.amazon.com/blogs/developer/upgrade-aws-sdk-for-net-for-latest-tls-protocols/
MYOB has advised that as of 30th September 2018 the MYOB API will no longer accept connections using TLS1.0
I have a Winforms application which connects to MYOB Accountright via the API using the SDK
I am wondering if there are any specific changes that I need to make to an application that I released 2 years ago.
I asked on the developer forum and was told that if my code uses TLS1.0 I need to change it.
From this question about determining the dot net framework I am thinking that I need to check the framework MYOB.AccountRight.SDK.dll uses.
Looking in my project I see that it is v4.0.30319
I opened MYOB.AccountRight.SDK.dll in notepad and saw NETFramework,Version=v4.5
From Stan Tarnovskly's blog I see
.NET 4.5. TLS 1.2 is supported, but it’s not a default protocol. You
need to opt-in to use it. The following code will make TLS 1.2
default, make sure to execute it before making a connection to secured
resource: ServicePointManager.SecurityProtocol =
SecurityProtocolType.Tls12
You don't want to be using TLS 1.0 or 1.1 these days.
This doc has some best practices and also several references to the upgrade path you should be looking at: https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls
We recommend that you:
Target .NET Framework 4.7 or later versions on your apps.
Target .NET
Framework 4.7.1 or later versions on your WCF apps.
Do not specify
the TLS version. Configure your code to let the OS decide on the TLS
version.
Perform a thorough code audit to verify you're not
specifying a TLS or SSL version.
Is there any dotnet core version of DocuSign.eSign Nuget package? or even source code I can fork?
DocuSign.eSign Nuget pacakge
Source code for C# client
There isn't any officially provided by DocuSign or alternatives that I'm aware of.
You could generate your own library with Swagger CodeGen and the DocuSign OpenAPI Specifications Swagger JSON
There is an unofficial fork of the C# SDK for .NET Core. Check the issues for the DocuSign C# SDK for a link.
Also, I'm looking to conduct 30 minute interviews with developers who are using DocuSign or considering to do so to get their opinions on how I can improve the developer products. Contact me via larry.kluger.docusign#gmail.com if you'd like more info.
After trying out both suggested solutions, it turns out that .net core SDK does not support the JWT Oauth workflow and it only support what's called legacy authentication method.
So, If you are trying to use JWT authentication using dotnet core SDK, you cannot
Is there any library available that can be used in the PCL that target iOS, Android, and Windows Phone 8 application using Xamarin, for implementing AES 256 encryption.
In .NET Standard 1.3 you can now do aes encryption/decryption and hashing https://xamarinhelp.com/cryptography-in-xamarin-forms/
Have a look at this link.
The author has the same problem and came up with these alternatives:
PCL Contrib
Bouncy Castle PCL
PCL Crypto
He also gives another workaround;
The other work-around is to use some dependency injection with
platform-specific code in each platform library and using it in common
projects. Xamarin forms provide a minimum depedency feature using
DependencyService. The only issue here is writing platform-specific
code and it is time consuming.
For more information on the DependencyService check out the Xamarin documentation.