Quick question.
There is a legacy website (that is not under my control and cannot be modified), that gives users a form to fill in data and then the user 'submits' the form for processing. There is virtually no error checking on this form, and very little help for the user (i.e. it was very poorly designed about 12 years ago and hasn't been updated since).
None-the-less, the back-end of this application performs a critical function.
My question is, is it possible (without having any ability to modify the legacy website), to write my own new front-end in asp.net (with proper pre-submit validation) living on a different server & domain, and then simulate the 'submit' to another webserver as long as I reproduce the form/data that is being sent?
The key question here I guess, is it possible to submit a form produce on one website, to another, and can this be done with ANY changes to the legacy site?
Comments appreciated.
The key question here I guess, is it possible to submit a form produce on one website, to another, and can this be done with ANY changes to the legacy site?
Yes, I've done this before - provided that the target site doesn't do any referer checking. A POST request is a POST request, no matter where it originates from.
You just need to make sure that all the fields are exactly the same in your request as they would be coming from the original page, i.e. - same field names, same encoding etc.
The short answer is "yes", the long answer is "it depends". The basics of HTML and HTTP allow for it, but without knowing a little more about the implementation of the legacy site you can't know for sure that it will work.
In theory you just need to make sure that the name of the fields are the same and set the target of the form to the legacy site's page URL.
In practice the legacy site could be doing various things that make it difficult or impossible to achieve (it could require cookies set correctly or hold internal state for example).
The best thing would be just to try it. It shouldn't take long just to mock up the basic fields and post the form to see if it works. Once you know it works then you can worry about adding your extra validation etc
Beware that if the existing site is authenticating users you'll need to find a way to also collect and pass that info along. Otherwise, though, Phill's point is spot-on.
Related
A very long title, sorry for that.
I'm looking for your input on the best way to support localization in an ASP.NET MVC 5 project in which i would like to pass the locale as part of the querystring. This way it would be easy for users to share a link to website and also pass the correct locale as part of the link.
If this would be done using, for example cookies, the user would pass a link but the page might be in a different language for the person who receives the link. I don't think that that is very nice.
The solution i currently use (http://afana.me/post/aspnet-mvc-internationalization.aspx) does not work nice with incorrect urls and just keeps loading the same page in loop. There is a lot of information on the web and i already went through a lot but i would like to know what is most commonly used and really works well.
As a bonus i would like the solution to work with attribute routing as my current solution doens't play nice :(
you can use resource files for that, the current culture is in the current thread of the web request, so no need to pass it in the querystring but it can be done;
have a look at this live demo: http://prodinner.aspnetawesome.com
you can download/read pdf about it here: http://prodinner.codeplex.com
you can see there that you can change the language using the dropdown;
in Global.asax.cs Application_BeginRequest, there's already code in there related to language, it reads a cookie now (or it's absence), you can make it read the querystring
I am building my own GridView in an ASP.NET project
I am drawing out my plans and I was wondering what the best solution is to a simple problem, paging and sorting.
The fast and easy way is using submit buttons (or similar) and POSTING the form back. That's also how the ASP.NET gridview works.
pro:
less overhead
con:
backbuttons
The second method is using links and the URL with GET requests.
pro:
backbuttons work just fine
direct link to certain position
con:
less reusable because of the dependence on url
The third method is AJAX
pro:
little overhead
con:
harder to implement
What design/solution would you pick and why?
Am i overlooking some pros and cons?
I add some extra comments to think about.
-The second method is using links and the URL with GET requests.
This is the one that you need to use, if your need web spiders (google) knows all the pages of your site, and be SEO friendly. This method have the problem that you can not have viewstate and each time you must render the page that you see on the url parameters with out knowing anything else.
With this case you probably have more problems if you wish to make edit on one line
-The fast and easy way is using submit buttons (or similar) and POSTING the form back
This is the method if you won to have many functionality on code behind because with the post back you have all the previous action that you have done, and the viewstate is working and can be used for that. Is not SEO friendly and if you like to make it you need extra code to write on the url just the page that you are now and need to land.
-The third method is AJAX
This is the method that must co-exist with the previous and not alone for the case that the browser fails to run javascript for any reason. If you do not care about that, the rest is that this method is also not SEO friendly and you need to make it, is cool, modern, and is a must for modern site, but if you going to make difficult things then you may end up with many issues that must be solved.
To summarize:
More than show data ? Post Request : Get Request ; // ToDo: make it ajax
I realized that many of my past projects have suffered from "too much ajax". I write pretty much all intranet "business" type apps so accessibility to older browser/disabled javascript/etc has never really been much of an issue for me. But things like unable to bookmark/go back/random errors/timeouts that the user doesn't see (I know there are ways around this but just as an example)...and most of all the development time is a lot longer (big issue for me I'm the sole dev) for what seems to be not a whole lot.
From people's experience - when is it appropriate to use ajax in business app/mainly CRUD type sites?
Take this as an example: I have a grid displaying all the registered users. One of the buttons takes you to an edit/details view where you can edit all the info and view further info not displayed on the grid. You can click "save" an ajax request is made and return either a success message or a modelstate with errors converted to JSON and that is displayed in a message above the "save" button (with a bunch of jquery that parses the result) all nice without a page refresh. I have many many screens similar to this. Would it make more sense just to redirect back to the grid displaying all the users once "save" is clicked and successful (with some sort of "flash message" on top stating save was successful) skipping all the ajax/json/etc? As the dev. I have a hard time imaging what would make most sense to the end users, but just doing a redirect would be much simpler and makes sense to me. What are people's experiences in these sort of scenarios?
In that scenario I would avoid AJAX all together unless you have a specific reason for it. Partial page updates, keeping a user's place on the page, or other reason.
MVC handles the scenario you describe very well, including the success/failure messages. In this "edit" failure case you'll detect the failure server side and return the same edit view back to the user with model state information. All of their fields will remain populated and you'll easily be able to display validation messages. On the success side you will return your list or index view and possibly use TempData to display a message to the user indicating their successful edit. A little javascript to spice that up and remove the message after 10 seconds or so and the user experience is very good.
This gets even better when you add client side validation, which is much easier in MVC3.
I think you can create a very intuitive experience for the user in this case and avoid ajax/json all together. I do both but I make sure I have a legitimate reason before I start writing client side ajax code.
Take a look at the Steve Sanderson MVC books. He walks through this scenario exactly as you described with good detail. His MVC3 book isn't out yet, and I haven't read the MVC2 book but the original MVC book has it.
http://www.amazon.com/ASP-NET-Framework-Experts-Voice-NET/dp/1430228865/ref=sr_1_4?ie=UTF8&qid=1308745293&sr=8-4
I also like PluralSight online training when I'm looking for fundamental framework guidance like this. http://www.pluralsight-training.net/microsoft/
Of course there are plenty of free blogs and what not that cover MVC too. Have fun.
In my application where I have to take a lot of data from the user that happens mostly form main business entities (Employeee, Distributor, etc.) I usually take the route of normal form post rather than ajaxifying the form. Mostly, I use ajax when data to be posted is small and I have to display data on same page after saving.
For instance, on Employees view page you can have a little form to add experiences for the employee and you can save it through ajax and append the entered data back to the same page.
Take the example of Stack Overflow for instance. They use normal form post for saving answers and questions but when it comes to comments where amount of data is small and comments have to be appended on the same page then it makes sense to use ajax in such scenarios.
I have a Plone Site where anonymous users create a "Subscription" object for a conference.
Fact is: a malicious user can call this screen a lot of times and crash my site. I can use a captcha to avoid it, but I would like to use it only after "x" attempts of the same user, something like the SO approach when a user tries to post a lot. Is there a module that does this for me? Show a recaptcha after a user tries the same url too many times?
For a start content in not the solution to everything. In your case having a custom content type for handling subscriptions seems like an overkill. Always ask yourself if what you are doing is really content-ish. Does it need to be contained, navigable, searchable whatever else content can be? For a conference subscription definitely not.
In brief you could:
Create a form and save its data in lighter objects than full content or use sql.
Use Products.PloneFormGen, which also has captcha support.
Concerning the captcha if you go the manual way and create everything yourself, you could use cookies to "remember" visits. See How do you get and set cookies in Zope and Plone?
It's obvious that your system is subject for manipulations in form of mass-registrations in every way without further measures like a captcha or additional email validation after submission of the registration form. But this is independent of flow control, DDOS etc.
Has anyone ever tried to integrate AspDotNetStorefront and Sitecore? I've been trying for the past couple of days to come up with a way to get the two systems to play nicely together, but it doesn't seem feasible from what I can tell. A couple issues I've run across so far:
Authentication between the two (AspDotNetStorefront has its own implementation, Sitecore just uses/extends .NET Membership)
The main DLL for AspDotNetStorefront is what pops up in the stack trace when I get yellow-screened, but that DLL is obfuscated so I can't figure out what the problem is.
The biggest issue is that we need to keep our existing AspDotNetStorefront application as an e-commerce backend and use Sitecore to do everything else. AspDotNetStorefront has a CMS as part of it, but it's really not an acceptable solution for anything but really basic content pages.
Any thoughts on how I might go about this?
EDIT:
I've decided to break this whole thing down into the different problems that I am facing at the moment and solve each one as efficiently as I know how. I'll detail the ones I have here and then update when I run into new ones.
Problem 1: Authentication between the two systems.
This one isn't too bad actually if you're knowledgeable about forms authentication tickets, which I wasn't at the time but am learning quickly enough. As long as the two systems share the same encryption info, it's easy enough to pass information back and forth between them using cookies as stated below in the accepted answer. The other kicker is that I needed to set the CustomerGUID in the AspDotNetStorefront Customer table to be the user ID from the Sitecore user tables (standard ASP.NET membership). So far this approach seems to work pretty well (I'm still in the proof of concept stage at the moment.
Another thing to keep in mind if you ever need to attempt this is that AspDotNetStorefront comes with a web service that you can use to basically do anything you need. Since they use the same encryption keys, I am able to log in on the storefront side using this service more securely than just passing over clear text passwords (I had to write the method myself, I don't believe it comes standard, if I am mistaken please let me know). Although I doubt it's a huge deal since it all happens server side anyways.
Problem 2: Getting at the product data
This one was a little more troublesome. The aforementioned web service has a few issues I've had difficulty working around. However, since the databases are going to be on the same server, I simply decided that since all I really need is the price and ID I would go ahead and set the ProductGUID column of each product in the Storefront database to match the Sitecore item ID of the corresponding item in the Sitecore database. This way I just need a quick query to grab the ProductID and price information which is only used in a few places. Everything else is going to be housed in Sitecore.
If anyone has anything to add feel free, as far as I can tell from Google, no one has actually done this before, so I'm having a lot of trouble finding resources on this particular topic.
UPDATE:
The integration is in fact possible and our site has been up for a week and a half now with very few integration related problems. This isn't something I recommend doing really on a personal level, but it is in fact possible to pull off.
I know ASPDotNetStorefront and other CMS systems (but not Sitecore). If I was approaching this, I would probably start simple and create a custom URL structure for sitecore 'content' pages that ASPDNSF would direct to Sitecore to handle. [possibly replacing the existing topics system in ASPDNSF]. So, for example: a URL such as www.domain.com/p-1234-aproductpage.aspx would be handled by ASPDNSF whereas www.domain.com/content/123/a-content-page would get sent to Sitecore to render. This is a straightforward web.config edit.
Security sharing across the systems should be possible across the same domain as the cookie information will be available (you should be able to create some code in Sitecore using the ASPDNSFCommon.dll and a cast of HttpContext.Current.User into a AspDotNetStorefrontPrincipal class to detect if a customer is logged in)
Another way to approach the problem would be to write a function that retrieved Sitecore content from the database based on a URL id and then write an ASPDNSF XML template to use the function to retrieve this content based on the URL. For example, you could create a custom URL structure in ASPDNSF such as www.domain.com/sc-1234-sitecore-content-item.aspx which is sent to your custom code; 1234 is used as the sitecore content id and the XML template retrieves the content and renders it on screen.
This second approach has the advantage of using Sitecore for all non-product content management while keeping the live application in ASPDNSF. Also one set of design templates and all your security issues go.