Looking for ideas. From within a web application (app #1), I need to call another web application (app #2), allow web app #2 to PRESENT FORMS TO THE USER, do some work, and then receive a result or return value into the original web app. The apps must be completely separated code bases. More than likely app #2 will need to be contained in a popup window but that is not entirely clear as of yet. There is a possibility that the single window may navigate to the second app. The apps are currently using ASP.NET and C#.
I originally thought of sending a "callback URL" to app #2, and allowing app #2 to post the result to app #1 through that URL, but then someone mentioned the need to do this as a modal window and NOT app #1 to navigate away from the calling page. On the other hand, if the receiving page was maintained on the back end, then it should always be possible to simply have the original app check for a session variable (or similar) since, as long as the browser for app #1 is not closed, the session content would still exist.
Thanks, in advance, for taking the time to respond.
If you want to communicate between two web applications, I would set up a Web Service interface in the second application. Then your first app can send "requests" to the Web Service that lives in the second app, and receive a response back.
MSDN has a lot of detailed information about this topic here: XML Web Services Using ASP.NET
The more specific places to get you started would be the guide to using Visual Studios web service creation wizard, and the examples of how to call a Web Service method.
This Stack Overflow answer has another way to call Web Service methods that might be more relevant to your use-case (calling via the URL).
Related
I have used the ASP.NET Core React project template to create a web application into which I've installed Identity Server 4. The React app takes care of all the user interaction, with the dotnet application used as an API only. I've integrated a Google OAuth2 authentication option using the services.AddAuthentication().AddGoogle builder extension provided by Microsoft.AspNetCore.Authentication. Finally, the whole thing is containerised and deployed to a Linux App Service on Azure.
Most of my code was ported from a previous version which was a very similar setup but in that case I'd added a custom React app to an existing ASP.NET application rather than start with the official React project template for dotnet. Back then everything worked well. But I'm facing problems with my new version when deployed to Azure. Here's a Fiddler trace to highlight the issue:
vault2 is a client of the identity service. identity-azure is the Identity Server application. The flow this trace shows is as follows:
User clicks Sign In on the Vault application
Browser is redirected to the Identity application
User clicks the Google button to initiate the OAuth2 flow
User signs in with Google account
User is redirected to the default callback URL (https://identity-azure.<domain>.com/signin-google?state=...)
This last step is where the problem is. You'll notice that you don't see the callback URL in the Fiddler trace, but instead you see a couple of other requests (e.g. service-worker.js) which are clearly being made from the React app. So the signin-google path is being handled by the browser's cached React app and not the server. The React app uses react-router-redux to handle certain routes client-side, and of course signin-google is not one of these so it appears to be returning an empty component.
As far as I can tell, all my ASP.NET routes (implemented using the Route attribute to decorate controller action methods) are handled consistently by the server. However, the signin-google route is implemented in the authentication middleware so as far as I know I don't have much control over it other than to change its path. Is there something I can do to force this to be handled server-side?
I should add that this behaviour is quite erratic. It seems that if my Google account is signed out then the above is observed, but if my account is already signed in then signin-google returns the expected 302 status code and the OAuth2 flow continues successfully.
I finally worked out what was going on. At least, I think I have. I can't be certain because I've since broken the React UI out into an entirely separate application but I was observing a similar pattern there. There was even a clue in my original question! Turns out the breaking pages were actually being served from the React app's service worker. I discovered this because even after breaking the React app out under its own domain leaving my identity-azure domain a pure ASP.NET Web API, requests for certain URLs under identity-azure were still behaving the same and I eventually noticed they were reporting themselves as being served by ServiceWorker on my browsers's Network tab. Example below.
As soon as I cleared the browsers application cache (in Chrome on Windows this was F12 > Application > Clear storage > Clear site data with Unregister service workers checked.
I'm not 100% sure what the solution would be if I'd left my React app in the same solution as the ASP.NET backend, but I presume it'd involve excluding specific URLs from service worker. I hope this helps someone in the future.
By the way, if you're thinking of building a fully decoupled UI for Identity Server 4, there's a great starter example here.
I have a console application that I wish to host on Microsoft Azure. I've designed a web form for users to submit two inputs necessary for the console application to run.
How can I get each input to the console application so that every time someone submits the web form, my console application runs in the background using those inputs and in return the console application sends them back the output in a .txt file or back to the web form directly?
Which Microsoft Azure services would I need to accomplish this?
To summarize the details from the comments, one approach is to abstract the console app into a class library so the output DLL can be used in the Console and in your web forms application. It is usually a security risk to try to run console apps from a web application since it requires elevated permissions with the OS that is usually best left alone.
To utilize this DLL in the web forms, you normally would add the dll as a reference to your web forms project. As you mentioned since you're not directly using Visual Studio, you should be able to drop the DLL into the "bin" directory of the web forms application. Your code behind should work so long as you use proper namespaces/declarations.
Long term, if your logic is complicated and time-consuming to where you begin seeing timeouts waiting for the response, you may consider asynchronous messaging patterns such as RPC:
The web form code behind submits the request into an outbound queue (such as Service Bus in Azure) as a serialized request with only user inputs and a correlation id.
A separate web application (such as a cloud service in Azure in a worker role) would monitor the Service Bus, then post result on inbound queue with correlation id. If this response is a large file or content, you could consider creating the file (such as Azure Blob Storage or AWS S3, but persist only shortly) and only returning response with reference to the file instead of file.
The web form would poll periodically the inbound queue for the correlation id and respond with details for the user.
How can I get each input to the console application so that every time someone submits the web form
If possible, you can contact webform project developer and let him insert message to Azure queue storage in webform submit event and set message body with user’s inputs value.
And you can make/modify your console application as QueueTrigger WebJob that will be triggered when a queue message is received.
Have just completed developing a WebAPI.
Now, creating an client application for the same.
To do this, I had created a WPF Client application which needs the user to enter the parent URI of the service.
That is,
http://localhost:65620/VirtualDirectoryName (Just the base URL not the entire URL)
Now, how to check if the URL is correct or not using the client application?
EDIT 1:
HttpClient can be used: But I am asking about validating the base URL alone.
Any ideas how to do this ?
(If I put the base address in the Browser, it shows the contents of the Directory. Then I assume that the installation is correct (At this point I am not calling any methods of webAPI though))
EDIT 2:
URL is Correct or not: I have to ensure that the service has been installed correctly in the IIS and it is up and running before any client could access its methods.
So you have a WebAPI that cannot be modified, and a client application that cannot be modified. You need to call one of the API methods using something, to check the API has been deployed correctly.
Either use the client application to call one of the API's methods.
Or create a test application which calls one of the API's methods.
I may be missing something, but surely there must be a simple GET method in your API that you can call from your test application that would prove the API is running.
I need to store data received from a remote device, i.e Application needs to run 24 hours so that it can capture data and store it in database.
I am confusing whether to create a console application, web application or any other i need to develop which will run continuously.
If you already have the application developed, then send the data to a web service. if you don't, consider creating a web page, either using ASP.Net or something like JQuery Mobile and push data to HTTP Handlers or Web Service.
If you go down the web service route, create a web method that accepts a request object and returns a response object. It should be a pretty simple design.
I have 2 web forms applications written in c# asp.net. This is the kind of thing I need:
A user clicks a button in web app 1
Web app 1 needs to send some parameters to web app 2 and get a response
Web app 1 uses the response from web app 2 to finish processing the post-back
User is happy
So I guess I need to incorporate some kind of web service thing into my web applications? Please point me in the right direction.
Update:
I've done some more research and found that WCF seems to be a goer. I have used WCF once before (stumbled through it) but how do I use WCF inside a web application - or do I need to create another application just for WCF?
Inter-process communication is a pretty large topic and there are many ways to do it.
Some tings to consider are
Synchronous vs Asynchronous - What should be the behavior if the user clicks the button twice in quick succession?
What should happen if user clicks the button but the web app2 is down for a few minutes?
Authorization and security
Denial Of Service style attacks
For something of this nature I would be inclined to use something like a message-queue maybe managed by something like nservicebus it would be a very simple, yet robust solution. WCF is another option and so is MVC 4.0 web services.