We are investigating using SignalR in our app for messaging. We want setup this messaging system as an app on its own. So our all our applications will connect to this messaging app to send messages. All this works fine but I am not sure as to how we can secure the SignalR messaging app. We only want our app to connect to it (basically our app users). If there are any other connections trying to connect, we want to reject this connection. Currently we set a query string parameter which can be validated on the server side but I am not sure how we can do our validation before the connection is made. I know in the hub we can override the OnConnected but this is too late. I want to refuse the connection before it starts.
Can someone point me in the correct directions.
We do that in our ASP.NET application. We have implemented an authentication module. We validate the cookie and the user in there.
Related
I have an ASP.NET Owin Web Api which is load balanced, which means there are multiple instances of it which don´t know each other. The web api hosts a SignalR hub with an SQL Server Backplane (for synchronising between instances), so clients can exchange messages regardless of which instance of the web api they are connected to. Everything working so far.
Client session data is stored in the db. The web api needs this info for processing requests for the client. Because it would be too slow to read the session data from the db for every client request, the web api is reading it only once (on first request from the client session) and caching it in-memory. This also works across multiple instances of the web api as every instance is holding it´s own session data cache.
But now the clients should be allowed to change for example the language, which results in an updated language in the session data stored in the db. The web api instance which processes the "change-language"-request of course can react to the changed session data and clear the session from it´s cache, which will lead to a reread of the session data from the db on the next client request. But the other web api instances don´t know about the session data change, their caches now hold outdated session data.
The web api instance which processes the "change-language"-request would somehow need to notify the other instances to drop their cache for session xyz. Unfortunately the instances don´t know each other, but all instances host SignalR hubs which are synchronised through the SingalR SQL server backplane.
Unfortunately a SignalR hub cannot directly send and receive messages. A HubConnection (client) is needed to do that. So the idea is when every web api instance is connecting to it´s own SignalR hub, it would be able to send messages to itself, which are then spread out to the other instances via the SQL server backplane synchronisation. But a HubConnection can only be established with an URL (http://host:port/signalr) but the web api instance doesn´t know it´s own base url.
So finally my question is:
Is there any way to establish a HubConnection to a hub running in the same process without providing an URL (I have access to the hub object)?
If not, is there any way for a SignalR hub to spread out messages and listen to messages through the backplane without a client (hub-2-hub communication)?
If not what else could I do to notify other instances of my load balanced web api and advice them to drop their session data cache?
Solved through distributed caching (IDistributedCache), as mentioned by Panagiotis Kanavos in the comments.
My .NET web app presently uses Azure Windows server VM to receive and send SNMP email. My users send email to my web app, and my Windows server VM receives this email into its SNMP and then deposits it into a folder, which gets read by my backend .NET app.
I'm interested in switching to the new Azure web app model, but can't find anywhere how it would receive email.
My DNS provider uses my MX RECORD configuration to forward email from my users to the IP of my present VM server and then to its SNMP receive service, etc.
To receive email with a Web App in Azure App Service, you can setup a Web Job that can poll for new emails on a Schedule or Manual trigger, then perform a custom action necessary.
Another alternative is that you could create an Azure Logic App that is wired up to be notified of email messages. This can be done using the Outlook connectors (if you're using an Outlook email) or other connectors. Then the Logic App can be setup to make an API call to your app to trigger some sort of custom action to take place for emails received.
The configuration you have today on a full VM can not be implemented in Azure App Service Web Apps. The underlying managed VM that hosts the Web App isn't accessible and configurable in this way.
Presently I use VisualBasic .NET web app (with SendGrid for email) running on my Azure server VM. I receives SMTP email from public Internet directly to the VM ok. It send email using SendGrid addon ok.
Will this all work if I switch to Azure Web App (formerly Web Site)?
Should my web app code work as-is without modification, even the SendGrid calls?
Outgoing email using SendGrid will not be a problem at all. Using it on App Service is common and you probably don't need to change any code at all.
Inbound may require changes depending on what you're doing. Are you simply polling a mailbox somewhere else and then doing something with the messages? If so, you could convert that to a scheduled WebJob poll at a specific interval and act on incoming messages.
If you're running an SMTP server on your VM to receive mail, then that's something you cannot easily replicate on App Service.
I'm looking for a way to support the following process:
Button is clicked in web application running on machine named PC1234.
Call is made to server (either the web server or an API on another server, it doesn't matter) to Do Something.
The server sends a notification to a Windows Forms client installed on PC1234 that the action is complete.
I've got the easy part working using SignalR. I can call a method on the web server and then send a notification with SignalR to ALL clients that the method has completed. The problem is notifying ONLY the client on the originating machine.
My initial plan was to include some unique identifying attribute of the machine with the call to the server which could then be used to direct the SignalR notification back to just that machine, but that doesn't seem to be possible.
An alternative idea was to have the call to the server include a unique reference and also update a file locally (i.e. a Cookie) with that reference, then have the client app poll the Cookie for new references and filter all SignalR messages received for that unique reference. This would be a bit clunky even if it worked, which it doesn't really, not least because I want this to work cross-browser, and different browsers store cookies in different places.
Ultimately this is to support printing locally and silently from a web application. The user selects a document in the web application, hits a print button, the request is sent to the server which retrieves the document from the database, saves it to a network share and sends a notification to a client app on the machine from which the print request was generated. The client app then prints the document from the network share and deletes it.
I never found a way to do exactly what I described in my question, but I came up with an alternative which worked well enough.
In both my web application and my Windows Forms client, the user was logged in with the same Windows credentials. I was therefore able to have the server respond to the button click in the web application by broadcasting a SignalR message to all SignalR clients where the same user was logged in, using
Clients.User(userId).send(message)
See this article for more detailed examples and instructions.
In my Windows Forms client, I included code to track how many instances of the client were connected to the SignalR Hub with the same user credentials and code to handle the receipt of a SignalR message from the server when multiple client instances were connected with the same user details (in my case, this meant displaying a message saying something like "You've requested a print from the web application but you're logged in at multiple workstations. Do you want the document to print here?").
I was thinking about integrating some instant messaging function into an existing ASP.NET web application, e.g:
the web application can display the online-status of users (are they currently logged in with their IM client)
users can send messages from the web application to the IM client of other users
users can initiate a IM chat from the web application (without having to know the other user's IM identification beforehand)
Does anyone know about some existing libraries, sample applications or other resources that might help implementing such a feature?
Thanks a lot for sharing your knowledge.
You should try Jabber. Demo client avaiable here.
There is an architectural overview, the main concept looks like this:
(source: webta.net)
And some citation from the site:
1. Goal
Create an multi-service instant messaging AJAX-based web application with internal accounting.
2. Main problem
We need to connect to IM servers from HTTP client (browser).
HTTP is a stateless protocol. This means that, theoretically, each HTTP request is being proccessed by separate http daemon proccess.
Once request proccessed (data sent to client), server fogets about client.
All IM services protocols are stateful.
When client connects to IM server, socket connection being created and connection much remain open for succesfull communication.
There's a list on the ASP.net site.
http://www.asp.net/Community/Control-gallery/browse.aspx?category=54
You might want to look at the .net implementation of jabber:
http://code.google.com/p/jabber-net/