Printable View
Hi All,
I request your valuable suggestions on this
I am planning to develop a software which will manage the inventory in a medical store of a hospital. The functionalities will include receipt of medicines from firms, issue to patients etc. There will be a few reports including current stock position.
Now I am confused whether to use VB or ASP for the development. Which would you suggest for this kind of an application and why?
Thanks in advance,
Binish
VB if the app is going to run on individual computers, ASP if it's going to run on an intranet server. Or maybe something else entirely - depending on what an analysis of the situation comes up with.
What tools you use and how you use them depends on the nature of the job. You don't first decide to use a power saw and a Phillips screwdriver, then analyze the job and find that you're being asked to dig a hole in the ground.
I suggest using VB desktop app, either way you will need a server to hold the data and generate reports.
ASP isn't very convincing for regular users in such applications as my experience taught me.
But the last time I checked it was up to the client to choose weather to create a web-based(ASP) app or a standalone app.
I vote for ASP, because you can have all your code in a single place with the database, you don't have to worry over computer-illiterates fumbling any updates you bring out, updates are easier since they occur only at the server, maintenance is easier, and there's no installation required, just the presence of a browser.
I am sure ASP would be elegant in terms of deployment and software updates. Besides the end-users are not very tech-savy and we need to train them.
What about the response time? In VB I can instantly display the stock balance in real time based on the quantity selected. I am not sure if this can be done with ASP, since it requires to submit the data and show the response.
If you are running this as a web page, the will depend on how busy your server is.Quote:
Originally Posted by Binish
Conversely, VB apps, using backend databases on network file servers, have the same constraint.
And modern AJAX techniques allow for the same kind of updating.
But I really wouldn't use ASP. It's quite simply obsolete. Use ASP.Net if you are comfortable with MS products, or perhaps Java Servlets.
Hey,
Thanks to Hack and CornedBee! I was not much aware of AJAX. Doing a research on it now... I am open to ASP.NET but don't have the tools right now. Need to wait till my company procures it.
A web app as its independant upon which OS it runs on, only browser compatibilities are needing to be dealt with. Its easier to update then having multiple apps on local workstations. Scalability is better but depends on the server resources.
Using a local win app is harder to keep all workstations updated but its dependant upon the workstation resources and OS for its issues. Also, it can be better performing as its all client side and only dependant upon the server's database and not IIS.
So depending on your environment and plan of scalability, you have the info to choose which is best for your situation.
In my case, there are only a few client machines. The application is not going to be much complex also. But it is desirable that it should be the least intimidating to the users who are not much computer-savvy. Besides, in this specific project, I am free to choose the technology. Hope I can settle for ASP
We keep the apps on a server and everyone runs a menu program that runs apps from the server (among other things - it also authenticates the user, because some people have access to some apps, some to other apps). Since all computers are at the same OS/Office level, there are no incompatibility problems.Quote:
Originally Posted by RobDog888
Thats what Terminal Server is for - "Application Sharing Server". ;)
I didn't realize you had the option of choosing a technology.
Yes, choose ASP.NET, it'll allow you to concentrate more on the logic of the application without having to worry too much about the UI.
AJAX is a good alternative in that it will update your page without page refreshes. However, keep in mind that if security is a concern for you, AJAX is something to avoid like the music of boybands.
How so?
With AJAX, it's quite easy to get to the request object and find out where the information is being sent, and then play around with those functions to 'hack' the page. Do you see where this is heading? Say you have to perform a secure transaction or you have to query a web service which you want only authorized/logged in users to do. You can set credentials in the request. In plaintext. So even if you use Windows authentication on a page, having an Ajax request on the page to a sensitive web service defeats the purpose of the authentication, since you can now make a request directly to the web service and not worry about being part of the group of users allowed to access it in the first place.
And then some developers would even say "Hey, I'll implement authentication in my client side code!" Whoop-dee-doo.
Sql injection attacks possible with poorly written code, but let's that one pass. But when it comes to databases, a simple look at the way the form info is being passed via javascript is another hole.
My point is, with Ajax, you now have multiple points of entry into an application.
Would you send, for the sake of an example, a credit card number or a password, in a simple post/querystring header to another page?
Then there's the bit about how it spits on the tiered architecture, but that's another story.
Don't get me wrong though, I do like Ajax, I'd only ever use it for information that I don't care about.
I am just starting with ASP.Net and I'm excited with its new features. My concern with this type of application is printing. How to create printouts with ASP.Net like the Data Reports? I've heard of SQL Server Report Services but not gone into details of it. is it for printing? or just how to do it in ASP.Net? (im using the express edition).
Thank You mendhak. That was a wealth of information!
With a simple package sniffer, it's quite easy to get ANY HTTP request and play around with it.Quote:
Originally Posted by mendhak
Yes. You're listing weaknesses of web-based applications in general and blaming them on AJAX.Quote:
Do you see where this is heading?
I can do such a stupid thing with normal HTTP requests too. Perhaps the temptation is a bit stronger with AJAX, but I actually doubt it.Quote:
Say you have to perform a secure transaction or you have to query a web service which you want only authorized/logged in users to do. You can set credentials in the request. In plaintext.
Let's assume I'm smart enough to use SSL. If I'm not, I have no business in sensitive applications anyway. Now let's further assume that SSL suffices to completely remove the threat of communications interception. It usually does.
Then there are two possibilities.
1) The user knows the credentials for the sensitive service. He has entered them on the page, in fact. Then there's nothing wrong with setting them in the request.
2) The user does not know the credentials. The web service is not part of my server, not actually part of my application, but instead extern to it. I fail to see what sensitive operations it could then perform, but let's assume it has some. It's perhaps a third-party app that I license, so I get credentials with which I can perform requests to them, and obviously I don't want to leak those credentials.
The problem if I want to access the service via AJAX is that I have to put the credentials to the client. That would be very stupid of me. If I didn't have AJAX, I might equally be tempted to write a form that gets submitted to the 3rd party service - along with the credentials, which I've probably written into hidden inputs. Again, the problem is not AJAX-specific.
What I would do, of course, is send an AJAX-request to MY server, which then checks the permissions of the sending user and forwards the request, along with the credentials (which thus remain on the server) to the 3rd party service.
Great idea. What's it got do with AJAX? It's only got to do with idiocy, as I see it.Quote:
And then some developers would even say "Hey, I'll implement authentication in my client side code!" Whoop-dee-doo.
Although ... what do you mean by authentication on the client-side anyway? AJAX is about sending requests to the server in the background. So if a developer wants to grab the login data, send it async, and only refresh the main page if the authentication was successful, good for him. No security hole there, as long as the authorization remains on the server side.
No, let's not. Putting SQL into cookies or anything else that ever touches the client is a topic for thedaily***.com - and there it's in the classic request-response model. AJAX changes nothing about this.Quote:
Sql injection attacks possible with poorly written code, but let's that one pass.
Really? How? It's collected, encoded into a request, and then submitted to the server, which is free to do whatever it wants with it.Quote:
But when it comes to databases, a simple look at the way the form info is being passed via javascript is another hole.
Wait a moment, the same thing happens when you submit a conventional form.
How so? You have endpoints for requests. If your framework is smart (mine is - how about yours?) it won't even make a great difference between normal requests and async requests - the logic should be the same, only the output code should write XML or JSON instead of HTML or XHTML.Quote:
My point is, with Ajax, you now have multiple points of entry into an application.
As POST data, yes, but of course only in SSL requests - which AJAX supports perfectly well.Quote:
Would you send, for the sake of an example, a credit card number or a password, in a simple post/querystring header to another page?
How would you do it?
Let me see. There's three tiers, right? The user interface, the business logic, and the data interface.Quote:
Then there's the bit about how it spits on the tiered architecture, but that's another story.
In a typical web app, the user interface part consists of everything that gets sent to the user, and the entire View part of an MVC server. The business logic is implemented entirely on the server, as is the database tier. They form the Controller. Then there's the Model, which is passed between the View and the two parts of the Controller.
In AJAX, the line is shifted. Some of the View part and sometimes a bit of the Controller part, a bit of intermediate business logic, is moved to the client. But if you structure your JS correctly, there's no need to actually mix the tiers, thus the model is preserved.
Also, I'd consider it bad design to move any but the most trivial business logic off the server.
Remember: application design is mainly about what the programmer does, rarely about the tools he uses.
I think you're missing potential. Just be careful - as always when you're handling sensitive data.Quote:
Don't get me wrong though, I do like Ajax, I'd only ever use it for information that I don't care about.
I vote for VB app
because use web forms (asp or asp.net) is may be dangerous ( you now hackers and bugs .... etc ) ,, and you said you develop app for hispotal ,, so the information must be safely ,,
if you will use VB app it is better to Encryption your app for Preventing decompile it
Thank You
Do you mean create a report for the person connected to the web page? My choice is Crystal to create a .pdf.Quote:
Originally Posted by eimroda
Let's see...
Easier with AJAX.Quote:
Originally Posted by CornedBee
Possibly.Quote:
Yes. You're listing weaknesses of web-based applications in general and blaming them on AJAX.
It is Ajax specific because of the hole it's just opened up. How are hidden inputs even a security solution? :ehh:Quote:
Let's assume I'm smart enough to use SSL. If I'm not, I have no business in sensitive applications anyway. Now let's further assume that SSL suffices to completely remove the threat of communications interception. It usually does.
Then there are two possibilities.
1) The user knows the credentials for the sensitive service. He has entered them on the page, in fact. Then there's nothing wrong with setting them in the request.
2) The user does not know the credentials. The web service is not part of my server, not actually part of my application, but instead extern to it. I fail to see what sensitive operations it could then perform, but let's assume it has some. It's perhaps a third-party app that I license, so I get credentials with which I can perform requests to them, and obviously I don't want to leak those credentials.
The problem if I want to access the service via AJAX is that I have to put the credentials to the client. That would be very stupid of me. If I didn't have AJAX, I might equally be tempted to write a form that gets submitted to the 3rd party service - along with the credentials, which I've probably written into hidden inputs. Again, the problem is not AJAX-specific.
What I would do, of course, is send an AJAX-request to MY server, which then checks the permissions of the sending user and forwards the request, along with the credentials (which thus remain on the server) to the 3rd party service.
And, if you send an ajax request to your server, what's to stop me from sending a request to it?
If it's a third party web service or page, since it's nothing but an httpwebrequest, I'm now allowed to do anything I want to with the third party page, replace the scripts, whatever. Sure, can be done with other languages, but I need to be on the server itself and add and register my own HTTPHandler.
Yes, check the referrers, read the headers. How many people know that? 14.
Of course, it's entirely possible to add more and more procedures to make this totally secure. More and more patchwork. Eventually blurring the lines. Soon we're at the point of creating convoluted procedures that would befit a true Chit-Chat thread.
Remember ActiveX? ;) It's got to do with idiocy, totally correct. You may or may not have a rose-tinted monitors, but it's the type of idiocy that a potentially great technology promotes.Quote:
Great idea. What's it got do with AJAX? It's only got to do with idiocy, as I see it.
I don't understand what you've said here.Quote:
No, let's not. Putting SQL into cookies or anything else that ever touches the client is a topic for thedaily***.com - and there it's in the classic request-response model. AJAX changes nothing about this.
Refer to the point of promotion of idiocy.Quote:
Really? How? It's collected, encoded into a request, and then submitted to the server, which is free to do whatever it wants with it.
Wait a moment, the same thing happens when you submit a conventional form.
[quote]
How so? You have endpoints for requests. If your framework is smart (mine is - how about yours?) it won't even make a great difference between normal requests and async requests - the logic should be the same, only the output code should write XML or JSON instead of HTML or XHTML.
[quote]
An implementation error (who doesn't make errors?) in Ajax is costlier than an implementation error in a codebehind solution. For instance... You have to validate more. Do you ever. And you'll miss out on more areas to do that. I wouldn't be surprised if I saw someone validating like it was the apocalypse and missing out on it right before submission. That's a problem I see with multiple entry points. It doesn't take a certified amphibian to see that. More points of entry = more chances of a mistake.
Your framework is smart, good for you. Keep working on it. :)
In my codebehind.Quote:
As POST data, yes, but of course only in SSL requests - which AJAX supports perfectly well.
How would you do it?
With the shifting of the line, a developer is now using two languages to do the same thing (due to a variety of reasons as you must know), he's on client and server code. And so when I deploy the code by sending it over to my incompetent server-deployment team, they punch themselves in the teeth. And we're also allowing others to look at part of our business logic. Why not just do away with the authentication and just request users to play nice?Quote:
Let me see. There's three tiers, right? The user interface, the business logic, and the data interface.
In a typical web app, the user interface part consists of everything that gets sent to the user, and the entire View part of an MVC server. The business logic is implemented entirely on the server, as is the database tier. They form the Controller. Then there's the Model, which is passed between the View and the two parts of the Controller.
In AJAX, the line is shifted. Some of the View part and sometimes a bit of the Controller part, a bit of intermediate business logic, is moved to the client. But if you structure your JS correctly, there's no need to actually mix the tiers, thus the model is preserved.
Also, I'd consider it bad design to move any but the most trivial business logic off the server.
Sure, structure the JS right. Even that can be flawed. Spend more time on QA. Go back and keep fixing it. And somehow... A simple view source and a clever pair of eyes is all it takes to look at it and figure out yet another way to bypass it. Partial thanks to poor debugging ( alert('blah blah blah') ).
Application design is about the programmers' thought process. With such increased complexity and poorly separated tiers, the programmer needs to understand and know the acceptability and limits, adhere to them without going overboard.Quote:
Remember: application design is mainly about what the programmer does, rarely about the tools he uses.
I understand the potential. Actually, I like to think I understand the potential. I've been working with Ajax for 6 years, and in these 6 years I've seen that for true, secure enterprise level applications, it's a bad, bad, bad choice. In fact, I think you see that too. You're a smart guy and I'm pretty sure you know what I'm talking about and how they're all possible.Quote:
I think you're missing potential. Just be careful - as always when you're handling sensitive data.
For personal sites, small-level sites, it's a wonderful tool. It's a wonderful tool with unnecessary marketing and hype, which is significant in our industry. There are better and improved browsers coming out soon. They will introduce new solutions and maybe new problems. But this is how it is right now.
Marginally. Those that need that ease aren't the ones who'll attack my application.Quote:
Originally Posted by mendhak
What are you talking about? What hole?Quote:
It is Ajax specific because of the hole it's just opened up. How are hidden inputs even a security solution? :ehh:
The hidden inputs are not a security solution. I explicitely said so. It would be stupid to use them. Just as it would be stupid to write data the user shouldn't be able to see somewhere JS code can access it.
You need to be logged in at my server for that request to be accepted.Quote:
And, if you send an ajax request to your server, what's to stop me from sending a request to it?
I have absolutely no idea what you're talking about, and especially how a HTTP request sent by JS differs, in the server's view, from any other HTTP request.Quote:
If it's a third party web service or page, since it's nothing but an httpwebrequest, I'm now allowed to do anything I want to with the third party page, replace the scripts, whatever. Sure, can be done with other languages, but I need to be on the server itself and add and register my own HTTPHandler.
And those 14 are wrong, because you can't trust client-provided data like referrer and headers.Quote:
Yes, check the referrers, read the headers. How many people know that? 14.
I still have no idea what you're talking about.Quote:
Of course, it's entirely possible to add more and more procedures to make this totally secure. More and more patchwork. Eventually blurring the lines. Soon we're at the point of creating convoluted procedures that would befit a true Chit-Chat thread.
ActiveX is a security problem because it allows a browser to start executing native code which cannot be, or perhaps just was not, sandboxed. The second part of the problem was that the browser thought it was a great idea to allow downloading this native code from somewhere and execute it, with only a prompt that most users didn't understand.Quote:
Remember ActiveX? ;) It's got to do with idiocy, totally correct. You may or may not have a rose-tinted monitors, but it's the type of idiocy that a potentially great technology promotes.
That's got absolutely nothing to do with AJAX. Being JavaScript code, it is executed in the browser's sandbox and hopefully has no way of escaping it. (And if it does, that's a security bug in JS, not in the specific usage as AJAX.)
Hmm, I misread your original post here. You said:Quote:
I don't understand what you've said here.
The point is, SQL injection attacks are about an HTTP request to the server carrying variables that are maliciously crafted to exploit poorly written database access code. If your AJAX implementation is so separate from the normal HTTP requests that it doesn't even share the DB access code, that's your own fault. If it isn't, the problem is reduced to something that is completely independent of the method used to access it, i.e. nothing to do with AJAX.Quote:
Sql injection attacks possible with poorly written code, but let's that one pass.
I just don't see where the potential security problem is.Quote:
Refer to the point of promotion of idiocy.
I believe that this indicates too much business logic on the client side.Quote:
An implementation error (who doesn't make errors?) in Ajax is costlier than an implementation error in a codebehind solution.
Not true. I have to validate each bit of data sent to server. I need to do that at least on the server, but it's usually a good idea to do it on the client too. That's true whether the data is sent asynchronously (AJAX) or synchronously (a conventional interface where each change requires a reload).Quote:
For instance... You have to validate more.
I simply believe that it is possible to write most AJAX stuff without duplicating much server-side logic, thus without increasing the attack surface.Quote:
That's a problem I see with multiple entry points. It doesn't take a certified amphibian to see that. More points of entry = more chances of a mistake.
Oh, I will, thanks.Quote:
Your framework is smart, good for you. Keep working on it. :)
That wasn't my question. My question was about how you'd get the data from the user (who needs to enter it at some point - or else I have again no idea what scenario you're talking about) to the server.Quote:
In my codebehind.
You've got a point here. Of course the complexity increases if there are effectively two interfaces, one conventional and one AJAX. Of course it either requires the developer to know two languages or else have the same thing (not quite - AJAX interfaces work differently from non-AJAX and thus use different logic) implemented twice by different developers. Still, it shouldn't be the business logic at the client, ever. The JS code should emulate the UI reaction to the given data and send an async request to the server to do the actual business logic.Quote:
With the shifting of the line, a developer is now using two languages to do the same thing (due to a variety of reasons as you must know), he's on client and server code. And so when I deploy the code by sending it over to my incompetent server-deployment team, they punch themselves in the teeth. And we're also allowing others to look at part of our business logic.
This, on the other hand, has nothing to do with the previous point and is a logical fallacy.Quote:
Why not just do away with the authentication and just request users to play nice?
I was talking about source organization.Quote:
Sure, structure the JS right. Even that can be flawed. Spend more time on QA. Go back and keep fixing it.
Don't ever implement sensitive logic on the client. I can certainly agree with you about that part. I just disagree that this means AJAX in general has no place in applications that handle sensitive areas.Quote:
And somehow... A simple view source and a clever pair of eyes is all it takes to look at it and figure out yet another way to bypass it.
I disagree about the poorly separated tiers - that's the entire point of application design. Really learning AJAX means to me knowing how it fits into the design of a web app without compromising it, how to make it a well-behaved tool instead of a hype going wild. It is limited knowledge of how to use AJAX that would lead to poorly separated tiers.Quote:
Application design is about the programmers' thought process. With such increased complexity and poorly separated tiers, the programmer needs to understand and know the acceptability and limits, adhere to them without going overboard.
You have definitely more experience than I, then, but I do wonder about the specific cases that you've seen.Quote:
I understand the potential. Actually, I like to think I understand the potential. I've been working with Ajax for 6 years, and in these 6 years I've seen that for true, secure enterprise level applications, it's a bad, bad, bad choice.
Because frankly, although I like to think of myself as a smart guy, I don't see it that way and for the most part don't know what you're talking about. It still seems to me as if you're blaming problems of the server-client model in general on AJAX specifically.
Actually, no. Not IE7, not Fox 2 or even 3 contain any new feature that will radically change the approach to building web sites. Sure, JavaScript 1.7 (as supported by Fox2) may lead to more readable JS code. Yes, client-side storage as in the HTML5 draft and implemented by Fox2 may enable having the same AJAX app running multiple times in different windows or tabs (right now this is difficult, because data of the two tends to mingle).Quote:
There are better and improved browsers coming out soon. They will introduce new solutions and maybe new problems.
But that won't change the fundamental approach. The web is still about sending a request to a server and getting a response back. AJAX doesn't change that - in only changes when these requests are sent, and what the browser does during that time and with the response.
Actually I see one problem. With the client-side storage interface, the temptation for programmers to transfer more business logic to the client increases. I see that as a danger and a wrong approach to AJAX. And abuse of a feature does not, in my book, justify banning that feature from a whole area.
(By the way, I wasn't saying Ajax is just like ActiveX. I'm referring to the potential this technology had, the hype it had around it and the security and architectural problems it brought with it. That's exactly like Ajax).
Buuuuuut, rather than answering all that, since I do understand exactly where you're coming from, and I understand your mindset, it won't serve either of us much purpose. Let me think of an analogy.
Ipods. Ipods are great, everyone loves an Ipod, everyone wants one. It is compact, large data storage capabilities, and it plays music. However, to get music onto it, you need to go through the ITunes software which uses its own directory naming structure for the purpose of 'whatever'. This means that you must now go through the software whenever you want to get music onto it. This means that you cannot get music from your friend's computer. (Forget DMA and other copyright issues, not the point here, look at it from a MP3-phile's perspective). You can get software which you place on the IPod which you can execute at someone else's computer, get their MP3s and be along your merry way. But, it is patchwork. It is a compromise that IPod owners are willing to accept.
Now, we can debate this all week, you'll keep analyzing it and telling me how you'd do it and I'd believe you. You're an expert, you would probably tweak and tune it and get it right. Would others? No. Like I implied earlier, only 14 people in the world can get an Ajax application right and it'll take them way too much time.
The moment you push something to the client, you must treat it as unsafe data. And you're totally right, business logic shouldn't even be there, but that is what's going to happen/is happening. This isn't about what is the unsafe data. One can think that they've covered all grounds and areas but the logical perspective of anything sent to the client is to look at it as unsafe data. In addition, one has to now write a patchy regression suite for their Ajax applications in the hopes... no, HOPES that they can cover all their scenarios.
Perhaps we've worked in two different methodology environments. I don't know what your environment has been, but mine has always been one for large enterprise environments and my mental conditioning and experience with it has brought me to these conclusions, I'll stick to it. We are nowhere near a "best practices" pattern for the whole thing and it'll be a long, long time before one does come out and when it does, I can pretty much write it on a piece of paper with a pencil that it will be unnecessarily complicated, it'll be an example of an architecture written around a technology. And all the heavy-duty/big business websites will still not use it, as they don't use it now, nor will I trust a 'secure' Ajax website soon. Later, maybe, not soon. Someday, when you write one I'd definitely want to hear your opinions on everything when you start working on it, right until the end. A blog or something...
So I'll end it at that and no, I'm not ignoring what you're saying. Again, I understand where you're coming from on all this, but it doesn't help me see things any differently.
Hm, I think I understand where you're coming from now, too. So I think we can agree that it is technically feasible to make AJAX (or rather hybrid, since I detest JS dependencies) apps that are secure, but practically very difficult to do due to the added complexity.
Yes. :)
By the way, have you ever come across the Dojo framework, or heard of it?
No, but I just googled it and will check it out.
Hmm ... first impression is that it's too flashy - it slows my browser down enormously - took about 15 seconds for loading the mail demo, with the browser not reacting at all.
Nevertheless, can be useful for some stuff.
You answered me before I had asked the question. :D
Yeah, I found it quite CPU intensive as well, if you look at the code, it's as though it's loading every single object whether they're required or not.
My follow up question was going to be, have you come across any other third-party frameworks similar to this? I was told about this last week, and I tried using it and uhm... you know.
The only other JS framework I know is Prototype, and it's for more low-level stuff. Actually it's a library, not a framework.