I have an Android app that talks to .net web service via http over TLS using self-signed server certificate. Now I am trying to figure out how I can accomplish the similar things (Import server certificate into the app and use http get protocol to talk to .net web service) in Blackberry phone.
Reading an article Blackberry support for HTTPS, my impression was that it might be more complex than in Android (for example, having Enterprise server and MDS between a phone and web server). Can I use Direct TCP Connection?
You can use
HttpsConnection cons=(HttpsConnection) Connector.open("https://xyz.com");
Related
Situation
So I'm thinking about building ASP.NET Core website to host it on Linux based hosting provider. But I still want to use MSSQL database, so best choice for that would be Microsoft Azure.
My Question
Now my question is rather security based, since I know, that hosting them on different providers is totally possible (Regarding this question)
But if I'm about to do so, then how will be my data encrypted? If I'm about to use default HTTP protocol, then I asume, it's not, but if to use HTTPS protocol, it should be encrypted as well? Or how would it work, do I need to setup some other protocols or security for that matter?
My Thoughts
Since Client won't be directly connected with Web Site to Database connection, then there is not chance, that this connection would be listened, yet this "might not be listened" is rather not a far chance. And if HTTPS is included, then all connections should be encrypted, then it should work same with Web Server to Database connection.
You can access Azure SQL from anywhere as long as IP address is in the firewall rule. Since communication to Azure SQL is on SSL/TCP at all times, data is already encrypted.
Ideally, you want to host Azure SQL and web application in same region not to mention same provider. The main reason is your website will be dramatically slow due to network latency, if you host those in different location.
Recently, Azure offers App Service on Linux. It is definitely worth the try, before considering an alternative route.
FYI: Web Apps on Linux does not yet support deployment of .NET Core apps from uncompiled source. You need to publish/compile your .NET Core app locally first, and then push the published site bits to your app.
I have a use case where we will have an ASP.NET MVC Server Application but it needs to talk over a persistent connection to a Windows service. It doesn't look like SignalR does this as it really wants talk Server to JavaScript browsers but I did notice .NET desktop libraries. Can it talk from a server to a Windows server? If not, is there a recommended way, TCP/IP or HTTP to have a persistent connection between the two? NetTcpBinding in WCF?
Yes, there is a SignalR client library for .NET that you can use in any old .NET app to talk to a SignalR server just like you can from JavaScript.
While there is a WebSockets binding for WCF, there is no binding that actually talks native SignalR which adds its own message framing on top of raw web sockets. So, while possible, it doesn't exist today and I wouldn't hold my breath for it ever being created.
Why not simply have a queue using RabbitMQ. And anytime the web need to talk to window service, it push a message into the queue while the window service listen to the queue
Tools : VB.net (VS2010), MySQL
I've a client desltop application connecting to my asp.net (vb) website. The desktop app typically sends a request and web app (server) responds to it.
Now, for certain scenarios, I would like website to connect to the client app and sends some data. How do I do it ?
I know client-server app (desktop app to desktop app) but not sure whether this can be done from website to destop app.
Any help is appreciated. Thanks.
You could use SignalR Framework.
From asp.net website : "ASP.NET SignalR is a new library for ASP.NET developers that makes developing real-time web functionality easy. SignalR allows bi-directional communication between server and client. Servers can now push content to connected clients instantly as it becomes available. SignalR supports Web Sockets, and falls back to other compatible techniques for older browsers. SignalR includes APIs for connection management (for instance, connect and disconnect events), grouping connections, and authorization."
Have a look here for documentation and tutorials : http://www.asp.net/signalr
There is a WCF Windows Service listening in netTcpBinding protocol, which I understand is Microsoft's proprietary protocol (correct me if i am wrong). I need to write a website that will consume the WCF services. I know for certain PHP can only connect to WCF Service in SOAP (basicHttpBinding or wsHttpBinding) so I need to write another SOAP proxy.
Some comments on the internet suggest that it is possible to have ASP.NET website connect to a WCF Service via net.tcp protocol. Is this actually true? Where should I look?
Your understanding about the netTcpBinding is correct. It is proprietary and accessible only from .NET clients. Since ASP.NET is .NET you could consume your WCF service without any problems.
Ofcourse an ASP.NET web application can connect to a WCF service using net.tcp binding but not over the internet! If the application and the service arn't on the same server or in the same intranet it will not work, you have to choose a HTTP binding.
From my comment below:
Yes net.tcp can work over the internet but not every circumstances it's not recommended (check it at MSDN) to use it. Ofcourse if the whole server control is our we can give it a try but if not (the application and service hosted by a 3rd party member) the chances are not so high to get it work (for example port blocking, the net.Tcp listener is disabled, net.Tcp port sharing is not working or disabled)
I hear HTTP endpoints are being deprecated in SQL Server. What takes its place in future?
Deprecated in favor of Windows Communication Foundation. So basically you would write and host WCF services in .NET which will directly talk to the SQL database and then consume those services from client applications.