Let's start having a quick look at some advanced functionality, because what we've seen so far is essentially just the basics.
What we have been doing when we have been automating is… we've been triggering events. Everything we've been doing is external through the application. We've been simulating what the user does. Simulating what happens when the user clicks on something.
When we normally consider automated execution, we very often talk about don't automate the GUI because it's brittle, automate at the API. Do more unit testing. Now, here we don't have an API, but we can simulate that if we had access to the innards.
If I have a quick look at the source code for this application, so on Sources > Page, I can see all the code for the app.
And there, in the example/vanillajs > js folder, is all the code for the app.
Now this app.js has a top-level app object.
Problem is, and you've seen this pattern from the bookmarklets, this is an anonymous function that runs immediately. The only reason it works is because it's setting up hooks onto the page to do the work.
It would be really useful if we had access to this
Todo object because then we'd have access to the
controller, and the
model and the
view and we will be able to do things in the actual application, but we don't.
If I go into the Console and say
I'm just going to show you a quick way to bypass this.
If I've got a breakpoint on this line in the code,
If I go into the Console now, that object that we didn't have access to, we now have access to. Problem is, if I let this code run to completion, it will fall off the end here and I will lose access.
What I want to do is, whilst we still have access to it, I'm going to create a variable,
myTodo and just assign
todo to it, and let's have a quick look,
There we go.
So, now if I run this to completion and go into the console, let me try and access the
todo object. I don't have access to it.
Let me access
myTodo object and I do have access to it.
We've essentially hijacked the object in mid-loading which can make things a little bit easier, because all of these objects within the
todo object have functionality.
Let me have a quick look at the
controller has the ability to add an item. So, let me try that.
If I say
There we go.
And this is perfectly valid, it's in the application.
We've triggered all of the events, and that's a lot simpler than writing all the code to trigger the events. But because of the way the application is written, we don't have access to that by default because it's in a private object.
This is the only way I know of hijacking this. Unfortunately, every time I refresh the page, I'll lose access to this, but it's a very simple enough step to manually interact with, and if I wanted to do things quickly in a very tactical fashion, this might be a very simple way of doing it.
When we were doing it previously, all we had to understand was: how does a browser work? How do events work?
Now we have to start understanding: how does the actual application work? How does this code work?
You just have to understand that there's a risk because we're no longer triggering the GUI events, we're now working at the application itself.
And it also demonstrates that nothing in the front end is safe or immune to manipulation by a user.
People very often use this pattern because they think, "Well, no one has access to it," but clearly, we can get access to it if we are determined.
The quiz for this chapter can be found in section 12.3