On Wed, Dec 8, 2010 at 9:18 PM, Sytze de Boer <[email protected]> wrote:
> Lets say I just want to have a system where > 1 Client logs in with password So, there's 400 - 1000 clients with unique and secure passwords. Where do these come from? How are the generated? How do you get them to clients? Email is insecure and passwords should _never_ be sent that way. Bear in mind a malicious user (client or hacker) with a password can find out if there are any security flaws (SQL overflows, flaws in your chosen platform) with the goal of taking over the machine for their own use. Any web application exposed to the internet is going to get probed by automatic scripts that have nothing better to do than try hundreds of well-known exploits; I see them in my web logs every night. Ideally, clients register with their email address, get a confirmation email with unique URL at that address (proving they have control of the email address), then get approved by the client as a known user. Then they can set their own secure password (and it should be checked for strength - not "password" or "1234") Then, there are always going to be some who forget their password. So you'll need a "forgot my password" link that can generate a one-time login URL and email it to the customer email on record. And some will want to change their password on occasion. Many web frameworks have bits and pieces of this installed. It's critical to get it right. (Btw, this also means it's not a "single table" app -- there's at least a "users" table, and likely a few more (like sessions) needed for management and administration. And an administrative app to manage them.) > 2 Now accesses a single table (or whatever is used to store data) This is the easy part. CRUD on a single table is pretty simple. But I'll bet there are some validation requirements. > 3 Only sees "his/her" data (like "set filter to " his/her data only) Also fairly simple. > 4 Has ability to Add/Change/Delete > Thats it, as simple as that Except for the next requirements, which for some reason you didn't number: > The system now pulls the data every midnight into a VFP app on a local > drive and pushes updated data back to web server. 5. So, the data needs to be tagged (new/synced), exported into a common format, securely transported to an authorized location. A second app on that machine has to import in the new information. What do you do if the data is invalid? Bad dates? Missing info? What if it conflicts with an existing records? Once the web app exports its data, how does it know it gets to the VFP app? Does it need to keep that data flagged as "pending" until the VFP app reports back that the data was imported successfully? How important (what are the business implications) of that guaranteed delivery, and what do you need to do to handle a failed transmission? Do you need to monitor the results each day? Are you allowed to take a vacation (holiday)? Important questions! 6. Then (or simultaneously, or before?) the VFP system exports its changes, transports them (securely) to the web app and a third application imports that data into the web app? Same questions as before: how do you handle a defective upload, an incomplete transmission, invalid data, conflicts? > Is this do-able (easily?) > S Of course it is! There's nothing that can't be solved. There's time, money and features: which of the three is fixed and which are you flexible on? As for "easily," there's nothing I see in your app that I haven't done before. If by "easily" you also mean "cheaply" and "quickly," well, pick two out of the three :) A fixed spec will get you a fixed project estimate. A vague spec will get you a vague "Sure! That's easy!" -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
