Pete Corey Writing Work Contact

Can Meteor Applications be "Mobile Only?"

Written by Pete Corey on Oct 17, 2016.

I recently finished up a security assessment with a team building a mobile-only application using Meteor.

One of the team’s goals was to prevent users from accessing the application through their browser. Their reasoning being that without access to the browser’s console, attackers would have a harder time exploiting any vulnerabilities that might exist in the application.

Interestingly, due to how Meteor applications work, truly removing the browser-facing portion of an application is impossible. Not only that, but removing the browser-facing user interface wouldn’t prevent a malicious user from exploring an application.

Uncovering the Bundle

We’ve previously talked about how a potential attacker (or security assessor) could extract a Meteor application’s server URL out of a compiled mobile application.

Armed with this information, the attacker can navigate to this URL, open up their browser console, and start poking your application.

But what if you wrapped your entire front-end in a Meteor.isCordova guard? Wouldn’t that prevent the attacker from being able to access the application with in their browser?

Wrapping your application in a Meteor.isCordova guard would initially prevent a potentially malicious user from seeing you’re application’s user interface. However, they would still be able to open their console and interact with your application’s Meteor object.

They can still inspect client-side methods, interact with Minimongo, call server-side methods, make subscriptions, etc…

Not only that, but a curious user could also view your application’s source and dive into your Javascript bundle. From there, they can peruse through all of the code used to render your user interface, paying special attention to method calls, subscriptions, etc…

On top of all of that, a highly motivated user could even redefine Meteor.isCordova to equal true when the application is initialized.

This would let the user view your user interface as if they were using a mobile device.

Ultimately, there is no way to prevent a motivated user from interacting with your application from their browser.

Final Thoughts

The battle for Meteor security (and all web application security) is fought on the server. Any client-side guards or precautions introduced into an application can easily be bypassed by a motivated user.

It’s important to remember that a user has complete control over their computer. This means that they have complete control over the portion of your application that runs on their computer. If the user tells your application to jump, it will ask how high. If the user says that Meteor.isCordova is true, then it’s true.

At the end of the day, the only real control you have over your application exists on the server. Take the time to secure your methods, publications, and server-side routes.

Phoenix Todos - Preloading Todos

This post is written as a set of Literate Commits. The goal of this style is to show you how this program came together from beginning to end.

Each commit in the project is represented by a section of the article. Click each section's header to see the commit on Github, or check out the repository and follow along.

Written by Pete Corey on Oct 12, 2016.

Redux Channel Actions

Connecting to our socket and joining our channel in the base of our application doesn’t feel like the React Way™.

Instead, let’s define actions and reducers to connect to the socket and join our "lists.public" channel.

We’ll start by creating a connectSocket action creator that initializes our Socket and connects it to our server. The corresponding reducer for this action will save the socket to our state:

export function connectSocket(jwt) {
  let socket = new Socket("/socket", {
    params: {
      token: jwt
  return { type: CONNECT_SOCKET, socket };

Next, let’s create a joinListsChannel action creator that joins the provided channel and dispatches addList actions for each list returned from the server:

  .receive("ok", (lists) => {
    lists.forEach((list) => {
  .receive("error", (error) => {
    dispatch(joinListsChannelFailure(channel, error));

Now we’re connecting to our Phoenix channel in a much more Redux-friendly way. Plus, we have access to our socket within our application’s state!


+import { Socket } from "deps/phoenix/web/static/js/phoenix" + export const SIGN_UP_REQUEST = "SIGN_UP_REQUEST"; ... +export const CONNECT_SOCKET = "CONNECT_SOCKET"; + +export const JOIN_LISTS_CHANNEL_REQUEST = "JOIN_LISTS_CHANNEL_REQUEST"; +export const JOIN_LISTS_CHANNEL_SUCCESS = "JOIN_LISTS_CHANNEL_SUCCESS"; +export const JOIN_LISTS_CHANNEL_FAILURE = "JOIN_LISTS_CHANNEL_FAILURE"; + export const ADD_LIST = "ADD_LIST"; ... +export function connectSocket(jwt) { + let socket = new Socket("/socket", { + params: { + token: jwt + } + }); + socket.connect(); + return { type: CONNECT_SOCKET, socket }; +} + +export function joinListsChannelRequest(channel) { + return { type: JOIN_LISTS_CHANNEL_REQUEST, channel }; +} + +export function joinListsChannelSuccess(channel) { + return { type: JOIN_LISTS_CHANNEL_SUCCESS, channel }; +} + +export function joinListsChannelFailure(channel, error) { + return { type: JOIN_LISTS_CHANNEL_FAILURE, channel, error }; +} + export function signUp(email, password, password_confirm) { ... } + +export function joinListsChannel(channel) { + return (dispatch, getState) => { + const { socket } = getState(); + + dispatch(joinListsChannelRequest()); + + socket + .channel(channel) + .join() + .receive("ok", (lists) => { + lists.forEach((list) => { + dispatch(addList(list)); + }); + dispatch(joinListsChannelSuccess(channel)); + }) + .receive("error", (error) => { + dispatch(joinListsChannelFailure(channel, error)); + }); + } +}


... import { - addList + connectSocket, + joinListsChannel } from "./actions"; -import socket from "./socket"; ... render(); -store.subscribe(render); -socket.connect();"lists.public", {}) - .join() - .receive("ok", (res) => { - res.forEach((list) => { - store.dispatch(addList(list)); - }); - }) - .receive("error", (res) => { - console.log("error", res); - }); +store.dispatch(connectSocket(store.getState().jwt)); +store.dispatch(joinListsChannel("lists.public"));


... SIGN_IN_FAILURE, + CONNECT_SOCKET, ADD_LIST, ... const initialState = { + socket: undefined, user: user ? JSON.parse(user) : user, ... }); + case CONNECT_SOCKET: + return Object.assign({}, state, { socket: action.socket }); default:

List Page

Now that our lists are being populated in the sidebar of our application, we should pull in the components, layouts, and pages necessary to render them.

We’ll grab the ListPageContainer, ListPage, ListHeader, and TodoItem React components from our original Meteor application and move them into our Phoenix project.

The main changes we’ve made to these components is renaming variables to match our Ecto models (incompleteCount to incomplete_count, and userId to user_id), and refactoring how we fetch lists.

Also, instead of using Meteor collections to fetch lists from Minimongo, we refactored our components to pull lists directly out of our application’s state:

let id =;
let list = _.find(state.lists, list => == id);

Now that we’ve added the necessary React components to our project, we can add the new ListPageContainer to our router:

<Route path="lists/:id" component={ListPageContainer}/>

Clicking on a list in our sidebar shows the (empty) list in the main panel. Success!


"brunch": "^2.0.0", + "classnames": "^2.2.5", "clean-css-brunch": ">= 1.0 < 1.8",




... > - {list.userId + {list.user_id ? <span className="icon-lock"></span> : null} - {list.incompleteCount - ? <span className="count-list">{list.incompleteCount}</span> + {list.incomplete_count + ? <span className="count-list">{list.incomplete_count}</span> : null}




+import ListPage from '../pages/ListPage.jsx'; +import { connect } from "react-redux"; +import _ from "lodash"; + +const ListPageContainer = connect( + (state, props) => { + let id =; + let list = _.find(state.lists, list => == id); + return { + loading: state.loading, + list: list, + listExists: !!list, + todos: [] + } + } +)(ListPage); + +export default ListPageContainer;


... if ( { - const list = Lists.findOne(; - if (list.userId) { - const publicList = Lists.findOne({ userId: { $exists: false } }); + const list = _.find(this.props.lists, list => ==; + if (list.user_id) { + const publicList = _.find(this.props.list, list => !list.user_id); this.context.router.push(`/lists/${ }`{:.language-javascript});




... import NotFoundPage from './pages/NotFoundPage.jsx'; +import ListPageContainer from './containers/ListPageContainer.jsx'; ... <Router history={browserHistory}> - <Route path="/" component={AppContainer}> + <Route path="/" component={AppContainer}> + <Route path="lists/:id" component={ListPageContainer}/> <Route path="signin" component={AuthPageSignIn}/> ... <Route path="*" component={NotFoundPage}/> - </Route> + </Route> </Router>

Preloading Todos

One of the cool features of Ecto is that we can write queries that automatically load, or “preload”, related objects.

For our Todos application, we can configure our List.public query to preload all associated Todo objects:

from list in query,
where: is_nil(list.user_id),
preload: [:todos]

Now the todos field on our List will be a fully populated list of all Todo objects associated with that particular list.

To send those todos to the client, we need to tell Poison that we want the todos field included in each serialized List object:

@derive {Poison.Encoder, only: [

We’ll also need to tell Poison how to serialize our Todo documents:

@derive {Poison.Encoder, only: [

Now on the client, we can tell our ListPageContainer to pull our list of todos out of the list itself:

todos: _.get(list, "todos") || []

After fixing up a few minor variable name issues, our todos show up in each list page!


... :incomplete_count, - :user_id + :user_id, + :todos ]} ... from list in query, - where: is_nil(list.user_id) + where: is_nil(list.user_id), + preload: [:todos] end


... + @derive {Poison.Encoder, only: [ + :id, + :text, + :checked + ]} + schema "todos" do


...{ - todoId: this.props.todo._id, + todoId:, newText: value, ... onFocus() { - this.props.onEditingChange(this.props.todo._id, true); + this.props.onEditingChange(, true); } ... onBlur() { - this.props.onEditingChange(this.props.todo._id, false); + this.props.onEditingChange(, false); } ...{ - todoId: this.props.todo._id, + todoId:, newCheckedStatus:, ... deleteTodo() { -{ todoId: this.props.todo._id }, alert); +{ todoId: }, alert); }


... listExists: !!list, - todos: [] + todos: _.get(list, "todos") || [] }


... todo={todo} - key={todo._id} - editing={todo._id === editingTodo} + key={} + editing={ === editingTodo} onEditingChange={this.onEditingChange}

Final Thoughts

Although it was briefly glossed over in the commits, representing the WebSocket connection process and state in terms of Redux actions led to quite a bit of internal conflict.

In my mind, a highly stateful, constantly changing object like a socket or channel connection doesn’t neatly fit into the idea of “state”.

Our Redux event log could show that we successfully instantiated a socket connection, but that doesn’t mean that the socket referenced by our state is currently connected. It might have timed out, or disconnected for any other unknown reason.

Trying to capture and track this kind of transient, ephemeral thing in pure, immutable Redux state seems like a slippery and dangerous slope.

We don’t track things like network connectivity in Redux state, so why track WebSocket connectivity? That analogy isn’t exactly accurate, but I think it helps to describe some of my concerns.

Ultimately, I decided to keep the socket connection in the application state so it can be easily accessible to all components and actions.

How to Safely Store Application Links

Written by Pete Corey on Oct 10, 2016.

Sometimes your Meteor application will need to store internal application links.

Maybe you want to save the last route a user visited, or maybe you want to associate notifications with a certain route within your application.

Storing URLs

It can be tempting to store these links as full URLs in your database and render them on the client as a simple anchor tag:

<a href="{{url}}">{{link}}</a>

Don’t give into temptation! This kind of linking can be a source of danger for your users.

If a malicious user has control over the URL inserted into the database, they can link other users of your application to potentially dangerous third-party websites.

For example, an attacker could manually create a new notification and provide their own URL:

  link: "Error dectected - please fix!",
  url: ""

Other users might see this “Error detected - please fix!” link, click it, and be redirected to

Evil Website® might attempt to deceive them, extract some information from them, or even be used as a vehicle for exploiting a Cross Site Request Forgery (CSRF) vulnerability on another website.

Storing Routes

Rather than storing the entire URL in your database, only store the information necessary to recreate the URL on the client.

For example, when using Iron Router (or Flow Router), it would be sufficient to simply store the route name in your database. On the client, you could use the pathFor helper to construct the link:

<a href="{{pathFor route}}">{{link}}</a>

Similarly, in-application links can be built using the <Link> React component if your application is using React Router:

<Link to=`${route}`>{link}</Link>

Building dynamic internal links like this is a much safer alternative to using raw anchor tags. It prevents attackers from potentially linking other users of your application to malicious third-party websites.