We currently host a lengthy form on our ASP.NET website, which makes use of a public facing facade WCF service to submit information over SSL into our network through a number of other facade services, etc.
We've experienced some issues with downtime on the service chain, and because of this some users have been very frustrated that they complete the lengthy form, only to find out after the fact that the service isn't up. Because of this, we are implementing a type of ping functionality on the form that will ping the service before the form is started, to ensure the service is up.
If the Ping() method is simply called during OnLoad of the form web page, there is potential for DOS attacks through for example a script that continually makes HTTP GET requests against the page.
My question is - From a conceptual level, what is the best way to ensure human interaction with the page while keeping it useable. For example, a CAPTCHA before the Ping() is called and form is started is way too intrusive even though it would be effective at ensuring the form is used properly. On the other hand simply allowing Ping() to fire OnLoad is far too risky for attacks.
One option I've considered is to have a button available to users which allows them to verify service availability and enable the form in one shot. This would at least be a balance between the two. I'm asking for your input on ideas for how best to balance this approach. Any asp.net, c#, or javascript/ajax based answers are fine.
Lastly - I also know there are flaws to this approach of checking service availability as there is no guarantee the service will be available by the time the form is filled out - but the decision has been made to use this approach so please keep your answers on point.
Thanks for the help and input in advance!
UPDATE 1:
In response to Josh's answer below - I should clarify that the form data submitted is sensitive and cannot be cached on the server or stored locally for later submission if the service fails. This is why it is very important to give the user a preemptive heads up. The issues we've had with the services are not intermittent so if the Ping() comes back true, there is an extremely good chance the user will not experience issues submitting the form a few minutes later.
UPDATE 2:
The Ping() Method is currently a server-side c# method, not javascript.
The public facing WCF service is IP-restricted to only allow requests from the public web server
Why don't you just call Ping() when the submit button is pressed and if the service doesn't respond then don't submit the form and show an error.
Something like this in jQuery. This assumses that Ping() returns true if the service is up, false otherwise:
$('#myformid').submit(function() {
var svcUp = Ping();
if(!svcUp)
alert("Sorry, there was an error submitting, please try again.");
return svcUp;
});
Unfortunately any public facing web service that has a low calling cost but high processing cost will be vulnerable to DOS attacks without some type of throttling.
Thankfully WCF has some useful settings for controlling throttling, take a look at MaxConcurrentCalls, MaxConcurrentInstances, and MaxConcurrentSessions
There is really no good solution on the client-side to prevent a DOS attack - I can create a script using your Ping js method that will call it a million times in a loop. You can prevent it on the server side though, by tracking calls per second form the same ip/session/user/otherclient-side identifier. If number of calls per second is over some reasonable limit, you temporarily ban that client.
You can look at http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx - scroll down to "Prevent Denial of Service (DOS) Attack" for an example
Call your function on page load and prior to the submit button. If you have any logging you are using you could insert into a log table for this particular aspx page view and include the IP address of the visitor. Set a threshold and if the IP makes more requests than what you required as proper usage, then put up some type of human-validation item.
Related
I'm working on an application and i want to understand it's behavior.
Once i have already logged into the system i make one request through ajax to the back-end, it's a void method that will process some information and feed a table.
Meanwhile i have another tab, also in the same session as the one that called the void method, and i want to go to the system's dashboard, so i press the corresponding button in the menu. This second tab will ONLY go to the dashboard when the void method is done.
Why? I would need static webservices to do that for me? I assumed that once it's a void method and i don't need its answer that would work.
You need to provide more details about the state of the application during the execution and the conditions around your requests.
If you're using AJAX to call the backend method and it doesn't return anything, your second request in the other tab should process normally. Web Applications are usually capable of handling multiple requests almost simoultaneously (barring any DDoS attack or unusually high load limits reached), so one thing i would ask is ¿are you debugging the application while sending the second request?, if you have a breakpoint on the server method that's being called and it's being hit by your first request, you need to step out of that execution manually before you can process the next request.
Another thing you might want to review is, if this method is a very resource/time-consuming operation, you might want to use tasks or threads to avoid creating bottlenecks between requests.
I am creating a website, where people can add each other as friend.
For example I got 2 users:
User ONE with UserID = 1
User TWO with UserID = 2
When User One adds User Two, I write this to a database, with an Integer to track the status:
0 = waiting
1 = accepted (are now friends)
If denied -> I just delete that record from the database.
When User One add User Two, I want to send a notification to User Two.
So User Two should get a notification about that User One has added him, without refreshing the page.
What can I use to create notifications after adding someone as friend?
Should I look to a kind of trigger on the database that sends something to the website after a record is added, or are there other mechanisms that you guys recommend me?
It's a ASPX website, without MVC.
The same mechanism I would like to use for a Message System.
There are 3 ways of achieving this, from simplest to most complex:
Polling
Write a javascript that calls a rest service on your site every x minutes and updates the DOM of the page
Long Polling
Similar to polling but keeping an open connection to have instant replies without waiting between polls. Requires having an api that can keep a pool of open connection and a background thread on the server that polls the database for changes, which it percolates up to the javascript if needed
Web Sockets
Upgrades the connection to a full two ways connection (websocket protocol). Similar to long polling server side.
As you can see any other option than 1. is fairly complex, but you can take a look at the SingalR library to get you started.
You can use AJAX to poll the database for such updates, AJAX is mainly used to refrain from forms submissions by acting asynchronously.
Here is a simple jQuery example of AJAX polling:
function doPoll(){
$.post('ajax/test.html', function(data) {
alert(data); // process results here
setTimeout(doPoll,5000);
});
}
Also, as Brad M commented, you can "cache" the "Friends" table into the memory and poll against it rather than the DB - It would be much faster.
I have a long running operation you might read in couple of my another questions (for your reference here is first and second).
In the beginning of whole deal, project expose a form in which user should specify all necessary information about XML file and upload XML file itself. In that method all user input data caught and went to an WCF service that handles such king of files. Controller got only task id of such processing.
Then user got redirected to progress bar page and periodically retrieves status of task completeness, refreshes the progress bar.
So here is my issue comes. When processing of XML file if over, how can I get results back and show them to user?
I know that HTTP is stateless protocol but there is cookie mechanism that could help in this situation. Of course, I may just save processing results to some temporary place, like a static class in WCF server, but there is a high load on service, so it will eat all of supplied memory.
In other words, I would like to pass task to WCF service (using netNamedPipeBinding) and receive results back as fast as it really possible. I want to escape temporary saving result to some buffer and wait until client will gather it back.
As far as I go is using temporary buffer not on service side but at client's:
using (XmlProcessingServiceClient client = new XmlProcessingServiceClient())
{
client.AnalyzeXmlAsync(new Task { fileName = filePath, id = tid });
client.AnalyzeXmlCompleted += (sender, e) =>
{
System.Web.HttpContext.Current.Application.Lock();
// here is I just use single place for all clients. I know it is not right, it is just for illustrating purposes.
System.Web.HttpContext.Current.Application["Result"] = e;
System.Web.HttpContext.Current.Application.UnLock();
};
}
I suggest you to use a SignalR hub to address your problem. You have a way to call a method on the client directly to notify the operation completed. And this happen without having to deal with the actual infrastructure trouble there is in implementing such strategies. Plus SignalR plugs easily in an asp.net MVC application.
To be honest I didn't really get the part about the wcf server and stuff, but I think I can give you more of an abstract answer. To be sure:
You have a form with some fields + file upload
The user fills in the form and supplies an XML file
You send the XML file to an WFC services which procress it
Show in the mean time a progress bar which updates
After completion show the results
If this is not want you want or this is not what your question is about you can skip my answer, otherwise read on.
Before we begin: Step 3 is a bit ambiguous: It could mean that we send the data to the service and wait for it to return the result or that we send the data to the service and we don´t wait for it to return the result.
Situation 1:
Create in a view the form with all the required fields
Create an action in your controller which handles the postback.
The action will send the data to the service and when the service returns the result, your action will render a view with the result.
On the submit button you add an javascript on click event. This will trigger an ajax call to some server side code which will return the progress.
The javascript shows some sort of status bar with the correct progress and repeats itself every x seconds
When the controller finishes it will show the result
Situation 2:
-
-
After sending the data to the service the controller shows a view with the progress bar.
We add an javascript event on document ready which checks the status of the xml file and updates a progressbar. (same as the onclick event in step 4 in situation 1)
When the progressbar reaches 100% it will redirect to a different page which shows the results
Does this answer your question?
Best regards,
BHD
netNamedPipeBinding will not work for cross-machine communication if this is what you have in mind.
If you want to host our service on IIS then you will need one of the bindings that use HTTP as their transport protocol. Have a look at the duplex services that allow both endpoints to send messages. This way the server can send messages to the client anytime it wishes to. You could created a callback interface for progress reporting. If the task is going to take a considerable amount of time to complete, then the overhead of the progress reporting through HTTP might be ok.
Also have a look at Building and Accessing Duplex Services if you want to use a duplex communication over HTTP with Silverlight (PollingDuplexHttpBinding).
Finally you could look for a Comet implementation for ASP.NET. In CodeProject you will at least a couple (CometAsync and PokeIn).
I'm not sure if this is the best solution but I was able to do something similar. This was the general setup:
Controller A initialized a new class with the parameters for the action to be performed and passed the user's session object
The new class called a method in a background thread which updated the user's session as it progressed
Controller B had json methods that when called by client side javascript, checked the user's session data and returned the latest progress.
This thread states that using the session object in such a way is bad but I'm sure you can do something similar with a thread safe storage method like sql or a temp file.
I have a class library I developed that is rather processing intensive that I currently call through a WCF REST service.
The REST service directly accesses the DLLs for the class library and more or less the WCF rest service is an interface for the system.
Let's say the following methods are defined:
Create Request
Starts a thread that takes five minutes, but immediately returns a session ID that the process generates and the thread uses to report when it is completed to the database.
Check Status
Accepts a session id and checks the database to see if the process has completed.
I have to think that there is a better way to "manage" the threads running, however, my requirements state that the user should receive an immediate response from the REST service upon issuing a request.
I am using the WCF Message property to return XML to the browser and as this application can be called from any programming language I can't use classic WCF and callbacks (I think, correct me if I am wrong).
Sometimes I run into an issue where an error occurs and the iscomplete event never gets written to the database and therefore the "Check Status" method says it's processing forever.
Does anyone have any ideas about what is normally done and what can be done in this situation?
Thanks!
Jeffrey Kevin Pry
Your service should return a 202 Accepted at the initial request with a way for the client to check the current status, either through the Location header or as part of the content.
As you indicate the client then polls the URL indicated to check the current status. I would also suggest adding a bit of cache time to this response in case a client just starts looping.
How you handle things on the server is up to you and in no way related to REST. For one thing I would put all logic that executes as the background thread in a try/catch to you can return an error status back if an error occurs and possibly retry the action depending on the circumstances.
I implemented a similiar process for importing/processing of large files and to be honest, I have never had a problem. Perhaps resolving the reason that the IsComplete never gets set will make this more resilient.
Not much of an answer, but still..
Background: I'm creating a very simple chatroom-like ASP.NET page with C# Code-Behind. The current users/chat messages are displayed in Controls located within an AJAX Update Panel, and using a Timer - they pull information from a DB every few seconds.
I'm trying to find a simple way to handle setting a User's status to "Offline" when they exit their browser as opposed to hitting the "Logoff" button. The "Offline" status is currently just a 1 char (y/n) for IsOnline.
So far I have looked into window.onbeforeunload with Javascript, setting a hidden form variable with a function on this event -> Of course the trouble is, I'd still have to test this hidden form variable in my Code-Behind somewhere to do the final Server-Side DB Query, effectively setting the User offline.
I may be completely obfusticating this likely simple problem! and of course I'd appreciate any completely different alternative suggestions.
Thanks
I suspect you are barking up the wrong tree. Remember, it is possible for the user to suddenly lose their internet connection, their browser could crash, or switch off their computer using the big red switch. There will be cases where the server simply never hears from the browser again.
The best way to do this is with a "dead man's switch." Since you said that they are pulling information from the database every few seconds, use that opportunity to store (in the database) a timestamp for the last time you heard from a given client.
Every minute or so, on the server, do a query to find clients that have not polled for a couple of minutes, and set the user offline... all on the server.
Javascript cannot be reliable, because I can close my browser by abending it.
A more reliable method might be to send periodic "hi I'm still alive" messages from the browser to the server, and have the server change the status when it stops receiving these messages.
I can only agree with Joel here. There is no reliable way for you to know when the HTTP agent wants to terminate the conversation.