Project 31-A

 Disclaimer: All opinions in this post are mine and not my employer (Microsoft). If you know of a more correct or performant way to accomplish work discussed in this post, please let me know at email javascript-developer@outlook.com . Many projects I work on are in progress by the time I work on them. I can't change previous design or architecture choices, but just solve a specific technical issue.  Secrets stored in Azure Key Vault All secrets for the React app are stored in Azure Key Vault. These secrets need to be pulled from Key Vault and set into the environment so that the `npm build` script uses those values. In order for the Azure DevOps Pipeline to connect to Azure Key Vault, you need to complete some work before you develop your Pipeline: Create a Key Vault and store your React build secrets, such as an Azure Functions key, used to authenticate and use the Function. Your secret doesn't have to have the same name as your React build variable. Please don't try. Ke...

Introduction In all development processes, you need to perform a security review in order to responsibly handle your user’s data . With my Windows Phone 7 application, the process turned into a huge decision and many incremental steps to handle. This blog post will enumerate how I took my unsecured WP7 app and corresponding Windows Azure website and secured them. This blog includes a detailed step-by-step of deploying a SSL certificate on Windows Azure. Process Summary DNS Name Change : Mapped my subdomain (wazup.berryintl.com) to my Windows Azure subdomain (*.cloudapp.net) via a CName change to my DNS on Network Solutions. Cert Provider : Found an SSL Cert provider. Dev Box/IIS : Created the certificate request in the IIS Manager. Cert Provider : Since I was requesting a wildcard certificate to handle all subdomains as well, I received two files: one for the domain and one to handle the wildcard subdomains. Dev Box/Certificate Manager : The next part of the pr...

Recently I was reminded (by being an observer to some drama) of the legal constraints that developers should know but frequently do not know – especially the new self-taught developers. I suspect that even some Computer Science graduates are ignorant here. Monkey See, Monkey Do –Lawyers Knock! Jack develops websites and a customer points him to a website that he wants emulated. Jack goes to the site and copy portions of the code from the site. Often the code is nothing more than a JavaScript function or a chunk of CSS. He uses these code fragments exactly as written (no renaming variables, changing line orders etc). He brings in a graphic designer that does a brilliant original design.   The site is ready, the customer is happy, Jack drops a check in his pocket.   Two months later, the customer phones Jack – he has just received a letter from a lawyer to take down the web site because it contains copyrighted material. Jack talks the customer into leaving it up. ...

For the last couple of days I have been thinking about how browsers send passwords across the network. I think I have a safer way. I would have to work at Microsoft or Mozilla to get this implemented however, I am content with blogging about it and getting some feedback. This is a line of code that as a web developer I write all the time: < INPUT TYPE =” TEXT ” NAME =” Login ” />< br /> < INPUT TYPE =” PASSWORD ” NAME =” Password ” /> This HTML delivers the login and password to the browser in clear text. The web application takes the password and concatenates it onto a stored piece of random text (called salt) and then hashes the complete string. This hash is compared with the hash store for that login and if they match then the web application can assume that the user knows their password. If the web developer implemented good security for his system then he never stores the password, only a hash of the salt and the password. The salt helps make every ha...