locked
Things you shouldn't spend time doing RRS feed

  • Question

  • User-760709272 posted

    In this thread I'm going to cover some "problems" that you shouldn't really spend time trying to fix or find solutions for.  When it comes to software development, some issues or problems are "political" rather than software and the real solution is to manage the client's expectations and requirements rather than spending your time trying to solve problems that can't be solved.  As a software developer, it is sometimes your job as a subject matter expect to simply tell a client that what they want can't be done, and to work on possible alternative solutions if possible. 

    I'm going to restrict this thread to questions that I see asked here frequently so that I can put my thoughts on these topics in more detail in a single place.

    1 Disabling the back button

    2 Disabling right-click \ view source etc

    3 Hiding the url or stop people amending it

    4 javascript only validation

    5 Stopping multiple logins \ multiple tabs

    6 Sending email via Gmail

    7 Scheduling tasks

    8 Automating Office applications

    Wednesday, December 10, 2014 6:02 AM

All replies

  • User-760709272 posted

    1 Disabling the back button 

    Can you disable the back button?  No.  "Back" is something provided by your client browser, it isn't a part of any http or web standards, it is a function many clients choose to implement for your convenience.  As it is not part of any standards there is no universal way of controlling it.  Have you ever seen a site that disables "back"?  If you've never seen a site do something, chances are it's not possible. 

    Should you disable the back button?  No.  Your code should concern itself with generating html, it should not interfere with the user experience.  People are used to using the Back feature and your site shouldn't alter this standard experience for them as it will only put them off your site. 

    Why do you want to disable the back button?  This is the key question.  There must be some reason you want to disable the back button, so you should explain what the problems your site is having with "Back" and someone will be able to advise you.  There are a few common problems with users going back, such as the site shows old data, and the solution to that is either

    a) do nothing as people are used to seeing old data when they go back and they are used to doing a refresh when they go back

    b) disable caching on the page that shows the data

    Another problem is that after a form submission, going back may trigger the prompt to refresh post data, it might take the user back to the form itself where it is tempting to re-submit the form.  The solution to this is to do a redirect to a static page after your form submission so redirect to a "thankyou.aspx" page for example.

    If you are using ajax to update content, do paging etc, then going back takes users to the previous page which might be some 10 or so user clicks ago rather than undoing your last ajax action.  The solution to this is to use the history api to update the url when you do ajax calls.

    These problems all have solutions so instead of asking "How do I disable the back button?", change your thinking and ask "When users go back my site does <explain problem>, how do I cater for this?"  Fix your code rather than trying to restrict the user experience.

    Wednesday, December 10, 2014 6:03 AM
  • User-760709272 posted

    2 Disabling right-click \ view source etc 

    Can you disable right click\view source etc?  No.  These are functions provided by your browser, it isn't a part of any http or web standards, they are functions many clients choose to implement for your convenience.  As it is not part of any standards there is no universal way of controlling it.  Have you ever seen a site that disables right click or view source?  If you've never seen a site do something, chances are it's not possible. 

    Should you disable the right click\view source?  No.  Your code should concern itself with generating html, it should not interfere with the user experience.  People are used to using these features and your site shouldn't alter this standard experience for them as it will only put them off your site. 

    Why do you want to disable the right click\view source?  This is the key question.

    For right-click are you trying to hide the page properties so people can't see the url?  I can see it from my browser tools or via Fiddler.  Are you trying to stop people doing a copy and paste?  Any javascript solution you come up with I can circumvent and copy and paste anyway.  Or I can view the html outside the browser and copy from that.  Trying to hide your source html?  I can get it from the browser tools or from Fiddler. 

    Anything you are trying to stop, people can get around so don't waste your time trying to stop it.  If there is some reason you don't want people to see the source then explain what that reason is and someone might be able to suggest a solution to your concern. 

    Wednesday, December 10, 2014 6:03 AM
  • User-760709272 posted

    3 Hiding the url or stop people amending it 

    Can you stop people amending the url or hide it completely?  No.  The browser has a job to do and that is to take urls and render the output as a page, and part of its interface is usually a text area where you can enter the url, and a text area that shows the current url.  These are functions provided by your browser, it isn't a part of any http or web standards, they are functions many clients choose to implement for your convenience.  As it is not part of any standards there is no universal way of controlling it.  Requesting any url you want is simply a part of the http process, you can't restrict what urls people request.  Have you ever seen a site that hides the url or stops you amending it?  If you've never seen a site do something, chances are it's not possible. 

    Also think about the security implications if sites could hide their actual sources?  It would make phishing sites that pretend to be eBay or PayPal or your bank much easier.  If you open a url using window.open then you can choose to show it in a popup with no address bar, but I can still right-click to see the url, or I can Ctrl-N to restore the window properties and see the address bar again.  Opening a popup this way might be visually pleasing, but it's not going to stop me seeing or amending the url if I want to. 

    Should you hide the url?  No.  Your code should concern itself with generating html, it should not interfere with the user experience.  People are used to seeing the url, it gives them a sense of familiarity and security, and more advanced users might also be familiar with amending the url as they see fit. 

    Why do you want to hide the url or stop people amending it?  This is the key question.  Do you want to stop people changing parameters?  For example if you are person 10 and your personal details page is 

    /PersonalDetails/View/10

    you might want to stop the user seeing the details of person 11 by simply changing "10" to "11".  The solution to that is to ensure the requesting user has the rights to the data they are requesting.  In my "View" action I will look at the user id of the current user and if their ID does not match the user ID on the url then I redirect to an "Access Denied" page.  Or let's say they are viewing an order using 

    /OrderDetails/View/1234 

    In my View action I will retrieve order 1234 and make sure it belongs to the person who is currently logged in and if it doesn't I will redirect to an "Order not found" page, or show a message saying the order couldn't be found.  Don't show messages like "That order does not belong to you" as that reveals that the order id itself is valid and that information could be used for phishing. 

    Other possible solutions to changing url params are encrypting the parameters, using GUIDs rather than guessable sequential IDs, or attaching hashed checksum parameters to ensure the data hasn't been changed by the end user.  At a later date I'll update this post to include same code for these techniques. 

    These problems all have solutions so instead of asking "How do I hide the url\stop people amending it?", change your thinking and ask "If users amend my url my site does <explain problem>, how do I cater for this?"  Fix your code rather than trying to restrict the user experience.

    Wednesday, December 10, 2014 6:04 AM
  • User-760709272 posted

    4 javascript only validation 

    Client-side validation is optional, server-side validation is mandatory. 

    Both Web Forms and MVC come with out-the-box validation frameworks that cater for server-side validation as well as client-side validation.  If you use these frameworks you get both client-side and server-side validation.  Client-side validation is a nice to have for clients that support it as it can provide instant feedback without the need for a form submission and a round-trip to the server.  However what if the client has javascript disabled?  If it is vital your data is valid for business reasons and I am a malicious user, remember that whatever javascript you enter, I can remove.  This will allow me to pass any data I want to your server-code and if you are not validating on the server then that could leave you open to hacking. 

    I'm not saying not to do client-side validation, not at all, I am simply saying it is an optional nice to have but server-side validation is something you must have as well.

    Wednesday, December 10, 2014 6:05 AM
  • User-760709272 posted

    5 Stopping multiple logins \ multiple tabs 

    Can you stop people logging into your site more than once from different browsers or machines?  No. The web is stateless, the server only knows you are there when you request a page, it has no idea who is "logged in" and who isn't.  The server doesn't keep an internal database or collection of everyone who is logged in, instead every time you make a request you pass your credentials and those credentials are validated for that request, and the second the request is finished the site goes back to not knowing if you are there or not. 

    There are some workarounds...you could keep in your own database to track when people log in and when they log out, but how do you know they have logged out?  What if they leave themselves idle and don't hit the "logout" button?  Their authentication cookie will expire so when they next request a page from your site they will be redirected to the login page, but as they never logged out your site still thinks they are logged in and will deny them access.  The result of this kind of solution is that your site admins spend their time constantly unlocking the accounts of annoyed users. 

    Also, why do you want to stop multiple logins?  What value does it add to your site?  Does your site malfunction or error in some way if someone has logged in multiple times?  If so then you should fix your code so that the site can cater for multiple logins, or at least fail gracefully if there are problems that can't be coded around.  Do you want to stop multiple logins to stop people giving others their credentials?  Well there is nothing you can do to stop that I'm afraid.  If gmail or netflix or twitter or Amazon etc can't stop you sharing your credentials with other people then you're not going to be able to stop it either. 

    The same goes for multiple tabs.  Can you stop users running multiple tabs?  No. 

    So instead of asking "How do I stop multiple logins\multiple tabs?", change your thinking and ask "If users log in to my site multiple times my site does <explain problem>, how do I cater for this?"  Fix your code rather than trying to restrict the user experience.

    Wednesday, December 10, 2014 6:05 AM
  • User-760709272 posted

    6 Sending email via Gmail 

    The short answer is; "don't", but I will try to explain why below. 

    There is a lot of misunderstanding around email and email protocols.  Receiving email (your "InBox", your email address etc) and sending email via your email account have nothing to do with each other, they are not related or connected in any way whatsoever.  There is actually no such thing as "sending email from your account".  The reason people think that sending email is connected to their account is because email clients (be they webmail or Outlook or whatever) handle both incoming and outgoing email in a seamless way that makes it appear as if they are connected.  You log in to your email client, you send an email, it appears to be "from" you and the email ends up in a folder in your mail storage.  It looks like sending and receiving are all part of the same system....but this is all smoke and mirrors by your email client. 

    From now on I'm going to forget about InBoxes, email credentials, email accounts etc etc etc and talk about how sending email works. 

    Email is sent via a protocol called SMTP (Simple Mail Transfer Protocol) which is an incredibly simple protocol (ergo the name).  You connect to an SMTP server, you say what address the email is from, who the email is to, and you then supply the body of the email.  The SMTP server handles the delivery for you via lots of various other internet protocols you don't really need to know about.  All you need to know is that the SMTP server has the ability to find out what server handles that the recipient email address and it will pass the message on to that server. 

    What SMTP server can you use?  Any.  What can the "from" address be?  Anything.  What can the "to" address be?  Anything.  All SMTP does is take the "From" address, the "To" address and delivers a message to the "To" saying "You have an email from <From address>".  Does the from address need to exist?  Or be your own actual address?  No.  Do you need to know the InBox credentials of the "from" address?  No.  The SMTP server has no way of knowing any of that, it simply sends the email.  Doesn't sound very secure, does it?  That's because it isn't.  When it was originally developed no-one foresaw issues like spam, phishing etc. 

    That's SMTP in a nutshell, but obviously in today's world of spam, SMTP servers do tend to be tied down slightly, and how tight they are tied down depends on what the SMTP server is designed to do, and how they are configured might dictate what you need to do in your code - there is no "one size fits all" code for sending email. 

    Here is the important point of this post though...you can send "from" any address via any SMTP server, the server you send the email through does not need to be connected to the "from" address, it does not need to be the server that handles the addresses inbox, it does not need to know your "Inbox" credentials.  If you want to send "From" "me@gmail.com" you do not need to send the email via gamil's SMTP servers, if you want to send "From" "me@yahoo.com" you do not need to send the email via yahoo's SMTP servers. 

    The ability to send "from" domains not connected to the SMTP server is a feature called relaying, and SMTP servers are picky about who they allow to rely through them.  If your site is hosted by a hosting company then the hosting company will have SMTP servers that should allow relaying from websites that are hosted by that company, ie servers on the same network.  If you are in an intranet or office network, again the SMTP server should be configured to rely from clients on the same network (if you have annoying system admins this might not be the case).  If you are a home user connected via an ISP then they might not allow any relaying, even to users on the ISP's network.  It all depends on how the SMTP server you use is configured. 

    If your webhost does allow relaying it might automatically know your site is on its network and just allow relaying, or the host might give you a username and password to send to the SMTP server that tells it you are allowed to relay.  How you connect to the host's servers is something you should ask the host. 

    So can your site send emails from gamil.com without using gmail's server?  If you have a decent web host, then yes, you should be able to. 

    Can you still send email through gmail anyway?  Yes you can...but you shouldn't.  In order to send automated emails through gmail you need to configure your gmail account to allow this.  Your sending is artificially tied to your account by google so you need to supply your email credentials to the SMTP server and if you change your mail password you need to change the password in your code.  If google doesn't like the strength of your password it will not let you send through its servers.  Gmail will not let you use any "from" address, it has to be the one attached to your credentials.  If you send too many emails gmail will stop you sending more.  If gmail thinks you should answer a "captcha" to continue sending emails then your code will start to fail until you manually log in and pass the "captcha".  Why put yourself through all this hassle and risk of your code suddenly failing because google has decided on a whim it no longer wants you sending email through its servers?  Sometimes people will start threads saying their code is failing and it is nothing to do with their code, it is simply google being awkward. 

    The solution is to not use gmail's SMTP servers, use the ones supplied by your hosting company.

    Wednesday, December 10, 2014 6:06 AM
  • User-760709272 posted

    7 Scheduling tasks 

    ASP.net is a response\request technology where code runs in response to an http request.  Making code run in response to a timer isn't something it was designed to do and isn't something that is supported.  There are workarounds like kicking off background threads that wake up to poll to see if there is work to do then go back to sleep, but the problem with these solutions is that you don't control your application lifetime, IIS does, and if IIS wants to stop your site running then it will.  So if you need a task to run at 10pm, there is no guarantee your site will be running at 10pm. 

    Libraries like Quartz.net will allow you to schedule tasks this way and it will work most of the time, but just remember it isn't bullet-proof.  If you have a task you want to run every 4 hours to clean up temp data or log files then it's fine to use these solutions as it doesn't really matter if the odd schedule is missed.  However if you have a task that absolutely has to run, and has to run at a certain time, then ASP.net based solutions are not the way to go. 

    The alternatives are scheduled tasks using the Windows scheduler, SQL jobs or Windows Services.  If you can use scheduled tasks then you could either write a console application that does the work you need to do, or you could write a console application that requests a certain page from your site, and the work can be done via that page.  You can then schedule this task to run when you need, and as long as the server is running your task will run. 

    If the work you are doing is pure database work you could do it using a SQL Job.  These jobs will be limited mainly to processing\deleting etc data in your databases.  SQL can also do things like send email etc so if you have a mail-shot task then it might be possible to do using just a SQL job. 

    A Windows service is another possible solution.  Unlike a console app that is ran via Windows scheduler, a Windows service is a task that is running constantly.  You don't "schedule" services, you don't start and stop services on a schedule.  What your service has to do is maintain its own lifetime and start a thread that wakes up periodically to see if there is work to do.  If you google for writing a scheduling Windows task you'll find plenty of sample code.  Again like a scheduled app the only work the service could do is to simply request a page from your site. 

    The main issue you are going to have with non-ASP.net scheduling solutions is if your host supports it.  If you are using shared hosting it is incredibly unlikely you'll have access to scheduled tasks, services or SQL jobs.  You'll really need your own dedicated server or virtual server, or to be running on a corporate network where you have access to these things.

    Wednesday, December 10, 2014 6:06 AM
  • User-760709272 posted

    8 Automating Office applications 

    Office applications are desktop applications, they are designed to work in an environment that has a GUI thread that has access to the desktop, and where it has complete control over its own threading and resources.  Office applications are not designed to be run in multi-threaded environments and Microsoft do not support automating Office from ASP.net.  They don't support it for a very good reason...you are never going to get it to work. 

    Office apps support automation so that they can be automated from other Office apps, your own Windows apps, VBScript files etc.  If you do manage to overcome the various security issues etc and get Office working from ASP.net (it can be done, I have done it myself), it will eventually fail.  How quick it fails will depend on how busy your server is.  You will end up with orphaned processes you have to manually terminate and eventually the whole thing will just stop responding. 

    People are often drawn into a false sense of security when they develop these solutions as they are developing locally on a desktop where the server and client are the same, using their Windows account, so their code is running with the right security and access to the desktop, in a single threaded environment...everything Office needs.  When they deploy to a production server everything goes wrong very quickly indeed. 

    If you really need to manage Office documents then look into products like Aspose, or the Open XML SDK.  It is also possible to manage basic Excel spreadsheets using the Excel ODBC driver which lets you treat the Excel file like a database, and use normal SQL select and insert commands to query or create rows. 

    There are no easy solutions to automating Office itself though.  The only real solution I can suggest is to have a Windows app running on a server that monitors a queue, and when requests come into the queue they are actioned by the application.  So the request might be to generate a Word document from a website, or create an Excel spreadsheet etc.  Your ASP.net code simply puts the request on the queue to be actioned by the application.  That way the Office automation is done by something able to properly do it.

    Wednesday, December 10, 2014 6:07 AM
  • User-1651604128 posted

    7 Scheduling tasks 

    ASP.net is a response\request technology where code runs in response to an http request.  Making code run in response to a timer isn't something it was designed to do and isn't something that is supported.  There are workarounds like kicking off background threads that wake up to poll to see if there is work to do then go back to sleep, but the problem with these solutions is that you don't control your application lifetime, IIS does, and if IIS wants to stop your site running then it will.  So if you need a task to run at 10pm, there is no guarantee your site will be running at 10pm. 

    Libraries like Quartz.net will allow you to schedule tasks this way and it will work most of the time, but just remember it isn't bullet-proof.  If you have a task you want to run every 4 hours to clean up temp data or log files then it's fine to use these solutions as it doesn't really matter if the odd schedule is missed.  However if you have a task that absolutely has to run, and has to run at a certain time, then ASP.net based solutions are not the way to go. 

    The alternatives are scheduled tasks using the Windows scheduler, SQL jobs or Windows Services.  If you can use scheduled tasks then you could either write a console application that does the work you need to do, or you could write a console application that requests a certain page from your site, and the work can be done via that page.  You can then schedule this task to run when you need, and as long as the server is running your task will run. 

    If the work you are doing is pure database work you could do it using a SQL Job.  These jobs will be limited mainly to processing\deleting etc data in your databases.  SQL can also do things like send email etc so if you have a mail-shot task then it might be possible to do using just a SQL job. 

    A Windows service is another possible solution.  Unlike a console app that is ran via Windows scheduler, a Windows service is a task that is running constantly.  You don't "schedule" services, you don't start and stop services on a schedule.  What your service has to do is maintain its own lifetime and start a thread that wakes up periodically to see if there is work to do.  If you google for writing a scheduling Windows task you'll find plenty of sample code.  Again like a scheduled app the only work the service could do is to simply request a page from your site. 

    The main issue you are going to have with non-ASP.net scheduling solutions is if your host supports it.  If you are using shared hosting it is incredibly unlikely you'll have access to scheduled tasks, services or SQL jobs.  You'll really need your own dedicated server or virtual server, or to be running on a corporate network where you have access to these things.

    Hi,

    For my case, create a window service is doing the main work, but client also want to see the task the window service ran, for example, the updated reports, some records created, so I need to show them in a webgrid view. so since window service does not have user interface, so there is no way to can provide them from window service , so in my case, I need to create a asp.net mvc web app with some webgrid to show the data generated by the Window Service. in this case, I need to main two applicaitons, one is window console apps and the other is a mvc web app., Please let me know if this is a good approach architecture. thanks

    This is the good example from start: http://www.c-sharpcorner.com/UploadFile/naresh.avari/develop-and-install-a-windows-service-in-C-Sharp/

    So based on the example above, there is no user interface for window service application, so for my case, I can create a window service application to do the main functions of schedule tasks - generate letters and send emails and create records in SQL database, and create another MVC web application with webgrid to display all letters with other information created in database. and add manual function in the mvc web app, so user can do any manu task from there.

    Is this a good architecture approach? thanks a lotj,

    Monday, March 2, 2015 1:17 PM
  • User-760709272 posted

    Your window service can write logs\status to a database or maybe to xml files on the drive, and you could build an application that accesses that database\xml files and converts the data into POCO objects that other clients can use.  So your mvc and console apps will both reference the same project and that project will have the code that analyses the data.  Another approach is to have the windows service host a WCF service that your clients can connect to directly and the service itself can return its data either by holding it in memory if it is just basis status stuff, or by reading back its own logs from the database or wherever.  That way your mvc and console apps can simply add a service reference and communicate with the service direct.

    Tuesday, March 3, 2015 3:44 AM