Thursday, May 15, 2014

Jeremy's Programming Blog - Create a self hosted API for Local Development

JeremyMorgan.com Newsletter

 
Sent to Insider Member blogs.sherrylinx.8442@blogger.com


Jeremy's Programming Blog - Create a self hosted API for Local Development

If you’ve ever worked in an overly restrictive environment, you know you have to come up with some workarounds to get your job done. I worked in such and environment and ran into a problem developing some front end pages to work with an API, but I didn’t want to use live data. Here’s a solution I came up with and I decided to write it out and explain it in hopes it will help others.

Tools Needed for this Tutorial (both free of charge):

Why a self hosted API?

When you’re developing front end stuff its always nice to have a development environment to work against rather than live data, as I explain in smell it before you eat it. But what if a development environment isn’t available? What if you can’t install IIS on your machine either? In that case you make a self hosted API to send fake calls to, and try to replicate the behavior.

You don’t need anything other than Visual Studio to do this, and it gives you a good starting point, and since everything is stored in memory you don’t have to worry about breaking anything important. There are some other cool uses for a self hosted API but today we’ll focus on using it to test your JavaScript front end stuff.

For this tutorial I’m going to assume you already know all about REST and some ASP.Net API basics.

Find out what you need.

First you need to find out which API functions you’ll need and map them out, because you’re going to have replicate them here, on a small scale. For the demo, we’re going to make something that stores a listing of books.

/API/Book

We want to be able to have some basic CRUD methods for it, so let’s set it up. For this you will need a copy of Visual Studio Professional, or Express 2013 for Windows Desktop. That’s what I’ll use for this demo.

1. Create the Project

Select File -> New Project

Choose “Console Application”

How to build self hosted Web API in ASP.Net"

Right click on your project and select “Manage NuGet Packages”

Search the Online Packages for “Microsoft ASP.Net Web API Self Host” and install the assemblies.

2. Set up the executable

Next we’ll want to add configuration data, so in Program.cs add the following using statements:

1  2  
using System.Web.Http;  using System.Web.Http.SelfHost;

And then inside in the static void Main() function add:

1  
var config = new HttpSelfHostConfiguration("http://localhost:31337");

Note that the port can be anything you want it to be.

Now create an instance of the HttpSelfHostServer passing in your config object as the parameter:

1  
var server = new HttpSelfHostServer(config);

Now create a task that calls the OpenAsync method and set the task to Wait:

1  2  
var task = server.OpenAsync();  task.Wait();

Next, we’ll want to output something to console to let you know it’s started, and put a Console.ReadLine in there to make sure it stays open until you want it to quit.

1  2  
Console.WriteLine("Server Up");  Console.ReadLine();

Note: At this time you can have a running service, but you must be running Visual Studio as an administrator. Now, if you’re in a restricted environment like I was you can’t do that, so you just have to code it with blind faith that it will work. You can run the finished product once it’s done, but if you are allowed to run as admin you can debug and test better.

3. Set up routing

Ok, so much of this doesn’t do you a lot of good until you can route your requests.

Open up the package manager again (Right click on your project and select “Manage NuGet Packages”) and search for ”Attribute Routing Self-Hosted”. Install the AttributeRouting(Self-Hosted Web API) package.

Now, open up Program.cs and add the following:

1  
config.Routes.MapHttpRoute("Default", "api/{controller}/{id}", new { id = RouteParameter.Optional });

This will handle the routing for your application.

4. Create a Model

In this tutorial we’re going to create a storage space for some books. Create a class that looks like this:

1  2  3  4  5  6  7  
    public class Book      {          public int Id { get; set; }          public string Title { get; set; }          public string Author { get; set; }          public decimal Price { get; set; }      }

This will obviously store some simple attributes for our books.

5. Create a Controller

Let’s create a class called BookController that extends the ApiController:

1  
public class BookController : ApiController

In that class we’ll want to create a few demo books every time it starts. We do this by creating a List of type book, and adding a few instances into it to start out:

1  2  3  4  5  6  7  8  9  10  11  12  13  
static List<Book> ourbooks = InitBooks();    private static List<Book> InitBooks()  {      var booklist = new List<Book>();        booklist.Add(new Book { Id = 1, Title = "Microsoft Visual C# 2012", Author = "John Sharp", Price = 29.99M });      booklist.Add(new Book { Id = 2, Title = "C# 5.0 in a nutshell", Author = "Joseph Albahari", Price = 19.99M });      booklist.Add(new Book { Id = 3, Title = "C# in Depth, 3rd Edition", Author = "Jon Skeet", Price = 29.99M });      booklist.Add(new Book { Id = 4, Title = "Pro ASP.NET MVC 5", Author = "Adam Freeman", Price = 34.01M });        return booklist;  }

Next, we’ll want to create a method to retrieve all books:

1  2  3  4  
  public IEnumerable<Book> Get()    {        return ourbooks;    }

This will return all the books in our list. Let’s open up fiddler and see what that looks like:

How to build self hosted Web API in ASP.Net"

So as you can see, a list of our items is returned with a GET request. This may be all you need, but if you need REST services, continue on.

6. Setting up REST actions

in our BookController, you’ll want to add a few more methods to add update and delete items.

Retrieve a book by ID (GET)

Let’s make it so we can select a book by it’s Id. Add a method to the controller that looks like this:

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  
  public Book Get(int Id)          {                var result = (from b in ourbooks                            where b.Id == Id                            select b).FirstOrDefault();                if (result == null)              {                  var resp = new HttpResponseMessage(HttpStatusCode.NotFound)                  {                      Content = new StringContent(string.Format("No book with ID = {0}", Id)),                      ReasonPhrase = "Book ID Not Found"                  };                  throw new HttpResponseException(resp);              }                return result;          }

This overrides the Get method, so if you pass it an Id, it will return some details for that book. As you can see if it does not find an ID it returns a 404 error, with a custom response.

Add a new book (POST)

To add a new book, we want to create a method that takes a POST command, and gets the JSON object from the body of the request. To that, add the following method:

1  2  3  4  5  6  7  
public void Post([FromBody]Book b)  {    b.Id = ourbooks.Count + 1;    ourbooks.Add(b);      var resp = new HttpResponseMessage(HttpStatusCode.Created);      throw new HttpResponseException(resp);  }

In order to add a new item to our list, we’ll need to change the request in Fiddler to a POST, and set the Content-Type:

Content-Type: application/json

And we’ll need to send it a JSON object, like this:

1  
{"Id": 0, "Title":"One More Book!","Author":"Jeremy Morgan","Price":1.99}

Your composer should look like this:

How to build self hosted Web API in ASP.Net"

Once you submit, run another GET request, and you’ll see the new object:

How to build self hosted Web API in ASP.Net"

It’s that easy! The next are even easier.

Update a book (PUT)

In this method we’re going to update a book using the PUT command.

Add the following method to your controller:

1  2  3  4  5  6  7  8  9  10  11  12  
public void Put(int Id, [FromBody]Book book)  {      var result = (from b in ourbooks                      where b.Id == Id                      select b).FirstOrDefault();        result.Title = book.Title;      result.Author = book.Author;      result.Price = book.Price;      var resp = new HttpResponseMessage(HttpStatusCode.Accepted);      throw new HttpResponseException(resp);  }

Now, if you run a GET in Fiddler, you should see a set of results as they are set by default:

How to build self hosted Web API in ASP.Net"

Since it’s a new instance the one we added will not be there.

In Fiddler (or whatever program you’re using) change the request to a PUT, and add an ID at the end (for the record you want to change). Then set the Content-Type to application/json and send the JSON string we used earlier. It should look like this:

How to build self hosted Web API in ASP.Net"

Once you send the put request, now send a GET and you’ll see the updated information:

How to build self hosted Web API in ASP.Net"

Remove a book (DELETE)

This one is really easy:

1  2  3  4  5  6  7  8  9  10  
public void Delete(int Id)  {      var result = (from b in ourbooks                      where b.Id == Id                      select b).FirstOrDefault();        ourbooks.Remove(result);      var resp = new HttpResponseMessage(HttpStatusCode.OK);      throw new HttpResponseException(resp);  }

Now, just set fiddler to delete an id and send it:

How to build self hosted Web API in ASP.Net"

And it’s deleted!

7. Build and use it!

So now that your application is ready, you can build and executable and use it for development.

Just build it, then look in your /bin/release folder and run it from there!

How to build self hosted Web API in ASP.Net"

Whenever it’s running you can connect to it like a standard web service.

So what’s the point of all this?

After reading this it might seem like a lot of work, but after you’ve done it a few times it’s really quick to whip it up. You might be asking, what’s the point?

The best use of this is to test the functionality of your application on a sample set of data. You can use this with a plain HTML/JavaScript page, asp page, or even another application. It’s a good way to test and develop your apps without using live data, or even accessing a live database.

Since you control what data is seeded in, you can write better unit tests for it knowing exactly what to expect. Since it’s only stored in memory, it’s really fast and resets as soon as you restart the executable. This can drastically speed up the development time and create better test cases.

Let me know if you use this, the code is on GitHub feel free to fork it and expand on it!


Do you like articles like this?

I’m constantly hacking on stuff and writing about happenings in the programmer world. You can subscribe to my feed here, or you can get the programmer newsletter 100% spam free!
     


More Recent Articles


 

 

Thank you for subscribing to my updates! 

Follow Jeremy on Facebook | Twitter | Linkedin

 

Email subscriptions powered by FeedBlitz, LLC, 9 Thoreau Way, Sudbury, MA 01776, USA.

 
Posted by at No comments:

Thursday, May 8, 2014

Jeremy's Programming Blog - 2 new articles

JeremyMorgan.com Newsletter

 
Sent to Insider Member blogs.sherrylinx.8442@blogger.com


Jeremy's Programming Blog - 2 new articles

Properties vs Fields in C#

One of the areas that causes a lot of confusion for new C# developers is the idea of properties and fields. It’s an easy thing to mess up and there aren’t really any solid rules on it, but here are some general guidelines to help you decide how to use these members in your project.

Definitions

Here are some quick definitions of what I’ll be talking about:

Properties - A property is a member that provides a flexible mechanism to read, write or compute the data of a private field. (From MSDN)

Fields - The private members of a class that contain values specific to the object

Methods - Methods are behaviors of an object, or “a code block that contains a series of statements” (From MSDN)

These are core parts of Object Oriented Programming as it relates to C#.

When should I use a property?

In general you should use properties if you need them to look and behave like a variable. Properties give you a level of abstraction so you can change the fields while not affecting how they’re used by a class.

Here are some basic rules:

  • Should be quick to read - reading a property should be just as fast as if it were reading a variable. If there are heavy calculations involved or you need to go to a database every time it’s needed, this isn’t the best way to use a property.
  • Client code should be able to read it’s value. - Write only properties are best reserved for methods.
  • Reading and writing to a property should not have any side effects - You should have no unexpected actions or side affects when working with this value. Changing this value should produce the results expected (like a color on a web page for instance) but changes should not be able to break the functionality of your program.
  • Properties should require an order - You should be able to set the properties in any order, you should not have any errors in a property if another property has not been set. This creates a dependency chain that can make your program unpredictable.
  • Validation and other logic is fine - you can encapsulate logic in properties, and adding an additional level of validation here is fine, if not recommended in some cases.
  • Read it a million times with the same result - You should be able to read the property multiple times with the same result. If you have a value that’s constantly changing like how much gas in the gas tank, a GetGasLevel() method would be better. If you want to store values that don’t change often like the amount of gallons the tank holds, use a property.

When do you I use a field?

Fields should nearly always be private members of a class, so you don’t expose internal implementation. They can be constants if necessary. Fields are used for data hiding, which is a best practice for Object Oriented Design:

In computer science, information hiding is the principle of segregation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed. The protection involves providing a stable interface which protects the remainder of the program from the implementation (the details that are most likely to change). (Wikipedia Definition)

You can perform any internal operations on a field, so long as it’s private and you can expose it’s value with a property. Here’s an example:

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  
public class Person  {     // name field     private string ourname;       // name property     public string Name     {        get        {           return ourname;        }        set        {           _name = value;        }     }  }

As you can see in this code we have the inner field named “ourname” and a Name property that’s available to the outside world. While in the code example above it looks like pointless ceremony but if you wanted to perform operations on the name, such as making it title case this would be a great place to do it.

If you don’t have any logic to perform you can use AutoProperties (C# 3.0 or later):

1  2  3  4  5  
public class Person  {     // name property     public string Name { get; set; }  }

This is much more concise and simple, if you need to apply logic to the value later you can always come back and expand it.

Summary

I hope that clears up the name vs property question when dealing with objects. Remember there are no hard rules here so if you really need to violate these guidelines you can, but remember some changes may make extension or interfacing difficult.

If you have any questions leave a comment!

     


Smell it Before You Eat it

Whether you’re developing for a personal project, small business or Fortune 100, you should take the time to make sure your changes aren’t going to break things. In times past this usually meant spending lots of money. These days the only thing you’ll need to spend for quality is time, and not much of it.

How the web commando publishes a web page

We all know how the web commando works. You have a website with files on it, and you download them via FTP (gotta have that latest copy!) edit it in a text editor and push it back up. .Net folks: edit and quick publish. You open up the browser and check it to make sure it looks good, and move on.

When I first started developing websites I did this too. At one time it was a reasonable thing to do, though still not a good practice. If you were on a small budget you couldn’t afford multiple servers, testing was pretty much unheard of and continuous integration was years away. So we did it, and we got away with it.

How a professional publishes a web page

In 2014, there is no excuse for being a web commando. Shooting from the hip is the product of laziness or sloppiness. These days a professional has the following things set up:

  • Development Environment
  • Staging Environment
  • Production Environment

Some even have a preview environment for managers. Here are a few things these environments must have:

  • The same operating system
  • The same version of engine (PHP, Python, Ruby, .Net, etc)
  • The same version of database back end
  • The same database schemas
  • The same configuration (sans Development)

I mention development should have a different configuration, that’s because you should turn error reporting on in development, but have it turned off in staging and live. This way you can catch your errors quickly in development, and see what it will “really look like” on stage.

Staging and Live environment should be identical. There should be no differences in configuration.

If you don’t want your staging accessing live data in the database, make a reasonable copy of sample data. The schema should be exactly the same however. You want completely predictable behavior from Staging so a push to to the live environment is seamless and worry free.

Note: I am not including continuous integration (CI) in this setup. That’s better tackled with it’s own article.

Here’s a diagram of an optimal setup for web development:

"Development Environment"

This is optimal, but not always possible.

The Workflow

So here is how the workflow goes in the diagram set up above.

  1. Developers create code and made changes.
  2. They push (with git or something similar) changes to dev.
  3. They run tests
  4. After they like the results, they push to the staging branch.
  5. Manager is notified “check this”
  6. Manager either approves or does not approve changes.
  7. If approved, Manager pushes to live (through git or other custom mechanism)
  8. Once live, the public or users can see the changes.

In an optimal situation the developers can pull down code to their local machine and connect to the development database. Some business rules don’t allow that, so we’ll assume they’re using a development server exclusively.

This is a great setup for small or large businesses as a baseline, to make sure you can see if how changes will affect the site, before your customers or users do (smell it before you eat it). While it seems simple, many organizations avoid this model entirely.

This model can be set up for little expense. You can actually have all three of these environments on the same server if you wish. You don’t have to have three physical servers to do this, due to virtualization.

Advantages to This Model

By using this model you have the following advantages:

  • Developers are able to “go wild” with changes, knowing that the live site will not be broken.
  • Managers can view the changes as if they were live, even though they arent.
  • If something breaks, you’ll see it before the customer does.
  • Management is given a good chance to evaluate everything. If they don’t like, they can cancel it and the end user will never know the difference.

There are some downsides however, but well worth it:

  • This setup will add to development time.
  • Multiple servers will have to be set up.

For most companies, a little extra time is a small price to pay to not have egg on your face when a live site goes down.

What do I Need?

At a minimum you’ll need a production server with two Virtual Machines. Whether you’re developing in a Linux Environment or Windows, virtualization is the way to go here. With Linux environments you don’t have the licensing hurdles so separate physical machines may be a better option.

You also need a deployment solution. I would recommend git for deployment, but SVN could work. Also using rysnc between stage and live isn’t a terrible idea. The reason you want to use these systems over FTP is simply for version control. If you don’t like something you can roll it back, also you can track changes much better. If you use Git from development to staging you can see exactly what was pushed when, and what changes were made. Using something like Rsync between staging and live ensures fast deployment of changes.

What Kind of Testing Should I Do?

In the next article I will describe methods of testing. At a minimum you need integration testing, and some kind of acceptance testing but optimally you should use:

  • Unit Testing
  • Integration Testing
  • Smoke Testing
  • Regression Testing
  • Acceptance Testing

I will describe these in full in a future article and show you some good software to use for this. I will also show some great tools to use for this.

Summary

In over a decade of development I have seen a lot of changes, and one of the least sexiest seems to be testing and deployment, yet they are the most important. Good quality software is a must for your organization. Most of the time you can’t reach the “ivory tower” level of testing and integration for your projects but the closer you can get the better. We live in a time where you don’t have to spend a lot of money and a little time invested has huge payoffs when your software works correctly as expected.

     


More Recent Articles


 

 

Thank you for subscribing to my updates! 

Follow Jeremy on Facebook | Twitter | Linkedin

 

Email subscriptions powered by FeedBlitz, LLC, 9 Thoreau Way, Sudbury, MA 01776, USA.

 
Posted by at No comments:

Thursday, May 1, 2014

Jeremy's Programming Blog - Smell it Before You Eat it

JeremyMorgan.com Newsletter

 
Sent to Insider Member blogs.sherrylinx.8442@blogger.com


Jeremy's Programming Blog - Smell it Before You Eat it

Whether you’re developing for a personal project, small business or Fortune 100, you should take the time to make sure your changes aren’t going to break things. In times past this usually meant spending lots of money. These days the only thing you’ll need to spend for quality is time, and not much of it.

How the web commando publishes a web page

We all know how the web commando works. You have a website with files on it, and you download them via FTP (gotta have that latest copy!) edit it in a text editor and push it back up. .Net folks: edit and quick publish. You open up the browser and check it to make sure it looks good, and move on.

When I first started developing websites I did this too. At one time it was a reasonable thing to do, though still not a good practice. If you were on a small budget you couldn’t afford multiple servers, testing was pretty much unheard of and continuous integration was years away. So we did it, and we got away with it.

How a professional publishes a web page

In 2014, there is no excuse for being a web commando. Shooting from the hip is the product of laziness or sloppiness. These days a professional has the following things set up:

  • Development Environment
  • Staging Environment
  • Production Environment

Some even have a preview environment for managers. Here are a few things these environments must have:

  • The same operating system
  • The same version of engine (PHP, Python, Ruby, .Net, etc)
  • The same version of database back end
  • The same database schemas
  • The same configuration (sans Development)

I mention development should have a different configuration, that’s because you should turn error reporting on in development, but have it turned off in staging and live. This way you can catch your errors quickly in development, and see what it will “really look like” on stage.

Staging and Live environment should be identical. There should be no differences in configuration.

If you don’t want your staging accessing live data in the database, make a reasonable copy of sample data. The schema should be exactly the same however. You want completely predictable behavior from Staging so a push to to the live environment is seamless and worry free.

Note: I am not including continuous integration (CI) in this setup. That’s better tackled with it’s own article.

Here’s a diagram of an optimal setup for web development:

"Development Environment"

This is optimal, but not always possible.

The Workflow

So here is how the workflow goes in the diagram set up above.

  1. Developers create code and made changes.
  2. They push (with git or something similar) changes to dev.
  3. They run tests
  4. After they like the results, they push to the staging branch.
  5. Manager is notified “check this”
  6. Manager either approves or does not approve changes.
  7. If approved, Manager pushes to live (through git or other custom mechanism)
  8. Once live, the public or users can see the changes.

In an optimal situation the developers can pull down code to their local machine and connect to the development database. Some business rules don’t allow that, so we’ll assume they’re using a development server exclusively.

This is a great setup for small or large businesses as a baseline, to make sure you can see if how changes will affect the site, before your customers or users do (smell it before you eat it). While it seems simple, many organizations avoid this model entirely.

This model can be set up for little expense. You can actually have all three of these environments on the same server if you wish. You don’t have to have three physical servers to do this, due to virtualization.

Advantages to This Model

By using this model you have the following advantages:

  • Developers are able to “go wild” with changes, knowing that the live site will not be broken.
  • Managers can view the changes as if they were live, even though they arent.
  • If something breaks, you’ll see it before the customer does.
  • Management is given a good chance to evaluate everything. If they don’t like, they can cancel it and the end user will never know the difference.

There are some downsides however, but well worth it:

  • This setup will add to development time.
  • Multiple servers will have to be set up.

For most companies, a little extra time is a small price to pay to not have egg on your face when a live site goes down.

What do I Need?

At a minimum you’ll need a production server with two Virtual Machines. Whether you’re developing in a Linux Environment or Windows, virtualization is the way to go here. With Linux environments you don’t have the licensing hurdles so separate physical machines may be a better option.

You also need a deployment solution. I would recommend git for deployment, but SVN could work. Also using rysnc between stage and live isn’t a terrible idea. The reason you want to use these systems over FTP is simply for version control. If you don’t like something you can roll it back, also you can track changes much better. If you use Git from development to staging you can see exactly what was pushed when, and what changes were made. Using something like Rsync between staging and live ensures fast deployment of changes.

What Kind of Testing Should I Do?

In the next article I will describe methods of testing. At a minimum you need integration testing, and some kind of acceptance testing but optimally you should use:

  • Unit Testing
  • Integration Testing
  • Smoke Testing
  • Regression Testing
  • Acceptance Testing

I will describe these in full in a future article and show you some good software to use for this. I will also show some great tools to use for this.

Summary

In over a decade of development I have seen a lot of changes, and one of the least sexiest seems to be testing and deployment, yet they are the most important. Good quality software is a must for your organization. Most of the time you can’t reach the “ivory tower” level of testing and integration for your projects but the closer you can get the better. We live in a time where you don’t have to spend a lot of money and a little time invested has huge payoffs when your software works correctly as expected.

     


More Recent Articles


 

 

Thank you for subscribing to my updates! 

Follow Jeremy on Facebook | Twitter | Linkedin

 

Email subscriptions powered by FeedBlitz, LLC, 9 Thoreau Way, Sudbury, MA 01776, USA.

 
Posted by at No comments:

Thursday, April 17, 2014

Jeremy's Programming Blog - What is Heartbleed?

JeremyMorgan.com Newsletter

 
Sent to Insider Member blogs.sherrylinx.8442@blogger.com


Jeremy's Programming Blog - What is Heartbleed?

On April 7th a security advisory was released titled “TLS heartbeat read overrun” (CVE-2014-0160) and it’s received a lot of attention in the IT community and the general public. Here’s a quick explanation of what Heartbleed is, and what it means for you.

Why are so many people talking about this?

"What is Heartbleed?" There are several reasons Heartbleed has received so much press. It’s a security exploit with a very wide reach, which means a lot of people are affected. It was also given a cool but somewhat scary name and a logo.

In other words it’s an exploit with marketing. This is a good thing because it gets the non technical public involved and that’s usually a great challenge.

According to the OpenSSL security advisory, Heartbleed is:

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.

Which doesn’t mean a lot to most people. Heartbleed is a bug with OpenSSL software, which is open source software used to secure communications on the internet. It allows an attacker to read chunks of memory on a web server they couldn’t otherwise read.

The Heartbeat Process

In short, here is how the heartbeat process works. A message is sent between the client (you) and a web server. It specifies the size and content of a message, and if the second server is functioning, it will return that same message back. This is done to make sure the connection is still present.

Here is an illustration of that process and how it theoretically operates:

"What is Heartbleed?"

In heartbeat process Server A prepares a message it expects to get in return and specifies the size of the message. If Server B does not respond, then the “heartbeat” is lost and it’s assumed the server is down. If it does respond it will send back the same message so Server A knows everything is ok.

Under an ideal situation Server B would send back the original message and nothing else.

The Heartbleed bug

Where the bug comes in is the size specification of the original message. If an attacker alters that size, they can send a message and receive back whatever size they asked for up to 65,536 bytes. This information is leaked from the Web Server’s memory, so it can contain RSA keys, usernames passwords or any other sensitive information.

Here’s a diagram of an attack:

"What is Heartbleed?"

It’s not exactly this simple, but similar. If the attacker finds encrypted information they can also find the keys, and a well executed attack can garner large amounts of information.

Who is Affected?

This affects any server using OpenSSL 1.0.1 and 1.0.2-beta. Since this exploit has been around for a couple years its unclear how many machines are truly affected. The safest bet is to change any password you can.

Here’s a list of passwords you should change right now.

Should I Panic?

No. This bug is being patched quickly and as long as you change your passwords you should be fine. Your personal computer is unlikely to be affected by this.


Do you like articles like this?

I’m constantly hacking on stuff and writing about happenings in the programmer world. You can subscribe to my feed here, or you can get the programmer newsletter 100% spam free!
     


More Recent Articles


 

 

Thank you for subscribing to my updates! 

Follow Jeremy on Facebook | Twitter | Linkedin

 

Email subscriptions powered by FeedBlitz, LLC, 9 Thoreau Way, Sudbury, MA 01776, USA.

 
Posted by at No comments:
Subscribe to: Posts (Atom)