Now that we have HTTPS connection end to end we need to run localhost over HTTPS for both the development and testing phases.

The final goal is to disallow all the non secure connections:

• Redirect the app from HTTP to HTTPS
• Redirect the registration server similarly
• Disallow non HTTPS connection to the box

In #3 I'm adding window.qr for debugging; this is a follow-up ticket for integrating this properly into the app's mvc structure.

In the scope of this bug we should update all places that rely on this event and likely introduce throttling support (if it's not supported inside React setState already)

Currently we use the following snippet during development:

gulp.task('watch-tests', function() {
  gulp.watch([`${TESTS_ROOT}**`], ['build-unit-tests']);
});

gulp.task('debug-unit-tests', function(cb) {
  runSequence(
    'build',
    'watch',
    'watch-tests',
    'run-unit-tests',
    cb
  );
});

We need basically the same, but a bit more polished.

I can see at least two issues so far:

• let is not supported
• No fetch API

Depends on #37

There is a getter that states whether the lightbulb is present (i.e.: "getter:[email protected]"). But on the UI App, all found service adapters are set to available. UI App should filter out the ones that are not present.

See fxbox/foxbox#290

• We need to somehow notify about breaking changes in API.

In foxbox logs we can see:

[2016-04-22 10:55:45.352] INFO [[email protected]] No need to create a new service for this rule; ID 'Motion Sensor detects motion, light gets turned on.' already exists.

But in the UI there is no warning, you can go ahead with the flow to create a recipe and tap on Done and even taken back to recipes list view as if the recipe was created, but it is not.

What do you think?
Thanks!

Hello @gmarty, there is one issue we would like to check in order to understand if there is a bug:
Scenario:
Running foxbox in pc1 with: cargo run -- -r http://knilxof.org:4242 -t knilxof.org:443 -s foxbox --remote-name test.knilxof.org --disable-tls
Running foxapp in a pc2 firefox browser: https://fxbox.github.io/app
Both in same network.
The list of devices is not retrieved.*

In the network console logs it is possible to see a GET to: test:3000/ping which never gets a 200 response.
Locally running both foxbox and foxapp in same pc is working, could be that fetching the remote url is done correctly but it is failing parsing it?

*Tried foxbox.clear() but then there was this error: Polling has failed, scheduling one more attempt: DOMException[InvalidStateError:"A mutation operation was attempted on a database that did not allow mutations"

Some ideas:

• Stop polling service list when we're at Recipe or Service view;
• When we're at Service view - we can poll only this particular service and maybe with different interval;
• We can ping the box only when we don't other net activity related to this box (no polling or watch request has been made for some time) or if some of the requests to the box failed for some reason we want to check if it's because of box unavailability.

@ferjm alread made the tunnel to be advertised on the registration server.

We should save that information if available and try to contact the box from outside the local network.

My foxbox is running on 192.168.0.24.
I do a cargo run on from that computer
I run the app using gulp from that computer

If I connect using http://localhost:8000 from that computer I get a splash
If I connect using http://192.168.0.24:8000 from that computer or another computer I get an "unable to connect"

When discovery fails (for instance when the Box did not register its local IP in the last 60 seconds), we silently fall back to using localhost:3000. We could add a warning when this happens (at least a console.warn something).

This was working for me before. Now I get the log in page, but it is like it does not detect the foxbox since the Connect to foxbox button never gets active...
Will try with other devices...

@gmarty spotted this odd behavior https://travis-ci.org/fxbox/app/builds/125043379#L426

In order to repro, apply this patch on top of ee6997d and launch npm test.

I suspect that sequence to not run stop-simulator when the previous task fails. Hence, a subprocess would still lives, that why it hangs.

• required fields should be exposed via getters and setters (where appropriate).

For now we're only targeting recent browsers: the latest Fennec and Chrome for Android.
They all support es6 features, so we can safely disable the es2015 preset of Babel.

In the future, as we add support for more browsers, we can only transpile the feature not natively supported in those.

When connecting to a Box for the first time, the app should note and remember the tunnel URL, and automatically switch to that if the Box's local hostname is not reachable.

As noted in #64 (comment).

Not urgent but maybe to have in mind...
The camera name is cut isntead of showing ellipsis:

New Recipe title seems not to be properly scaled:

Thanks!

When the local IP address of the box on the network changes, the lib still tries to connect to the previous one.
We need a mechanism to detect changes in the IP address.

There are several recipes in recipes list view, if you refresh the page, it dissapear, you have to go for example to home tab and then to recipes tab again so the list is shown again.
Having the app open via: https://fxbox.github.io/app

Right now, the user must first create an admin password on http://192.168.0.42/, before they connect to http://app.knilxof.org (or wherever we will host the app in this repo). That makes the whole discovery mechanism in this app pretty useless :)

possible solution: send the user straight to app.knilxof.org and do the admin user creation from there, but that's something we should discuss, because:

• Will we also allow third-party apps to create the admin user?
• If so, will we whitelist the origins from which this is allowed?

When the discovery server returns several boxes, the user should be able to select one.

We hit that frequently in the office...

@azasypkin or @gmarty is that something you can look at this week?

The current deployment script, deploy.sh, is executed until the end even if one of the previous steps fail, potentially leading to an unstable/buggy version of the app online.
If we use a Gulp task, the process will stop at the first error.

With the same version of foxbox and foxapp I was able to take a picture without problems but it stopped working.

I can see in the console: "Error occurred while making a snapshot: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data" when tapping on the button to take a snapshot and the next screen with the view of the picture is not shown.
Although in the foxbox traces I can see that actually the picture was taken: [2016-04-14 11:11:14.042] INFO Took a snapshot from ae67e622-7a66-465e-bab0-b0c5541a6eb4: /Users/irios/.local/share/foxbox/snapshots/ae67e622-7a66-465e-bab0-b0c5541a6eb4/2016-04-14-111114.jpg_

*One thing I have not done before I saw this issue was trying to add a recipe including the camera, but it was not added as per bug issue #68 and also I closed everything and launched both foxbox and foxapp from the scratch.

Created a recipe 'Everyday in the evening, Camera take a picture'
Then I removed it with the 'x' button
I tried to create it again but was not able, I click on Done and although I taken back to the recipe list view it is not added and got this error in foxbox:

(this log is since I start creating it for the fist time)
[2016-04-14 17:31:11.098] INFO Thinkerbell: Starting compilation of script 'Everyday in the evening, Camera take a picture.'
[2016-04-14 17:31:11.098] INFO Thinkerbell: Starting execution of script 'Everyday in the evening, Camera take a picture.'
[2016-04-14 17:31:11.100] INFO Added Thinkerbell Rule for 'Everyday in the evening, Camera take a picture.'
[2016-04-14 17:31:20.583] INFO Removed Thinkerbell Rule for 'Everyday in the evening, Camera take a picture.'
[2016-04-14 17:31:38.342] INFO Thinkerbell: Starting compilation of script 'Everyday in the evening, Camera take a picture.'
[2016-04-14 17:31:38.343] INFO Thinkerbell: Starting execution of script 'Everyday in the evening, Camera take a picture.'
[2016-04-14 17:31:38.345] INFO No need to add new ThinkerbellRule; ID 'Everyday in the evening, Camera take a picture.' already exists.

Please see below screenshot:

Should it be expected to have a number or name to differenciate them? or should it be the tag (which btw is not saved if it is selected for a service)?

If reg server ping fails (for example because of a error like "knilxof.org:4443 uses an invalid security certificate." fxbox/registration_server#19), we start pinging an invalid /null/ping url. We shouldn't do that.

comma-dangle
arrow-parens

The rationale behind the coding styles is that it should result in cleaner git diff and code easier to read.

We can choose more suitable and sensible polling intervals using data provided Using Network Information API [1]. Connection type (wifi or radio) should definitely be considered.

https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation

Not sure this is also related or caused by issue 77
Once the app is open, from the home view change the status of a light from on to off. (Due to issue 77 you first have to uncheck the check box and then check it again so the light is on)
If you log out and then log in with same user, the light status according to the app is on, but it is actually off.

Babel react conserves the propTypes of components (which is both expected and wanted).
But in production mode they add no benefits to the components so we want to remove them.

Let's enquire and see if it's a common practice in the React world and if there are already tools to do that.

Foxbox is running in one network, launch https://fxbox.github.io/app from a device connected to a diffferent network. The log in page is loaded but when tapping on Log in button the Set up page is not shown instead it appears an error to connect to the site.

cc @JohanLorenzo, @npark-mozilla

It is kind of confusing now..but we can live with it till having more devices supported there...

Problem:

We are making good progress on FoxBox discovery inside a trusted local network, but if the local network is not trusted, an attacker inside your WiFi network could become a Man-in-the-Middle (MitM) between client and FoxBox, spying on your data, and possibly even replaying the commands sent.

Step 1: Trust on First Use (TOFU)

We assume no attacker is present during the setup phase, but once the app has discovered the FoxBox, comms should become TLS-protected, so that a MitM can only attack during the setup phase, and not at a later point in time.

Step 2: QR-code-base

To make the setup phase secure as well, the user should bring the client physically close to the FoxBox, and then somehow tell the client "this physical object is the one I want to connect to". I'm calling this QR-code-based because that provokes a clear mental image, but you could also use NFC, a USB cable, a PIN code, etc. to achieve the same.

To do:

• TOFU-based secure discovery
  • Use https server-side on the FoxBox (this is fxbox/foxbox#14)
  • Client-side implementation in Cordova
    • Look at ES5 problems in Cordova build (this is blocking the next point)
    • Add Cordova build target (this is #3)
    • Implement TOFU in https://github.com/michielbdejong/SecureHTTP/commits/master
  • Client-side implementation in WebExtension
• See if TOFU can be done at the OS level instead of at the application level
  • on Android
  • on Windows 10
  • etc ...
• QR-code-based
  • Work out the https://<fingerprint>.foxbox<i>.<special-tld> idea in more detail
  • Server-side implementation (just set the hostname based on the signing cert's fingerprint)
  • Remove reliance on [m]DNS - i.e. allow using an IP address instead of a domain name
  • Implementation in Cordova
  • Implementation in WebExtension
• Coordinate this work with FlyWeb - they have the exact same problem

As per [1] we shouldn't rely on return value of ReactDOM.render and TestUtils.renderIntoDocument because of:

ReactDOM.render() currently returns a reference to the root ReactComponent instance.
However, using this return value is legacy and should be avoided because future versions
of React may render components asynchronously in some cases. If you need a reference
to the root ReactComponent instance, the preferred solution is to attach a callback ref to
the root element.

It's also a reason of some unit tests intermittent failures we have currently.

[1] https://facebook.github.io/react/docs/top-level-api.html

It becomes a huge problem if IndexedDB contains something that is no longer available in this case we always think that number of services has changed and we fire corresponding events and trying to re-render UI and more...

This one should include Travis integration as well

We need this for Recipe page, so that we can distinguish getters and setters there.

Probably this would be fixed in the future, or maybe is this way as per design but does seem coherent to me being in camera details view and having as active the home view tab. What do you think?

Let's switch to eslint that supports JS and JSX out of the box!

With latest changes I am not able to open the app from a different device (android mobile with chrome beta).
https://fxbox.github.io/app opens log in page but upon tapping on log in button the Not possible to connect to this web site is shown

When we remove the transpilation to es5 (see #44), we want to concatenate and minify the build.
AFAIK, there's no minifier that support outputting es6 code, so we can use something like https://www.npmjs.com/package/mangle-my-js by @jonathanKingston

Some Foxboxes don't use any hosted services. In the current box-client discovery proposal, this will be the default build for Foxbox.

Some other Foxboxes will use Mozilla-hosted services, and others still will use self-hosted services (hosted by the end-user or their friend, or by a hardware-vendor, OEM, etc.).

To discover and interact with all these Foxboxes, this app has to support not only the DNS-server+registration_server+LetsEncrypt discovery flow, but also the mDNS + TOFU discovery flow.

There are two ways to build this app: as a Cordova app, or as a statically-hosted (client-side) web app.

We obviously love using web apps rather than Cordova apps whenever possible, but in this case that comes at the price of functionality: only the Cordova build of this app will be able to support mDNS + TOFU discovery.

That's why I propose to make the Cordova build the default way to build this app, and make "deploy to gh-pages" only an option, adding a warning that "not all Foxboxes will be supported".

I wanted to get some feedback to see if anyone sees any alternative paths of action here, before moving forward with updating the readme with this change. Will also post a link to this issue to the mailing list.

Here an screenshot of what I have

@gmarty A few things related to the status of the light services:
I am using only light bulb 2, the other two are not connected, I would expect the other light services to be greyed out or shown in a different way?
Also the checkbox for all of them appears as clicked which is the status for on, and they are off.
And, about the red square, should it change to green when turning on the light?

I added several comments here, since not sure they are actually issues, if they are, I can open separate issues if you prefer. Thanks!

Preliminary we want to import [1] and [2] including all existing unit tests. This will require some changes to make it more "es6-classy". And we need to decided whether we want it to be base class or mixin, or maybe both.

[1] https://github.com/mozilla-b2g/gaia/blob/master/shared/js/event_dispatcher.js
[2] https://github.com/vargin/event-dispatcher/blob/master/event-dispatcher.es6.js

Currently if we have let's say Service 1, Service 2 and Service 3. They are saved in Indexed DB, when user opens the app we display services in particular order, but once we receive service list from the box the order of these services can change sometimes even if we still have the same services.

IIRC @fabricedesre was the one who was particularly complaining about this weird behavior :)

We don't have websockets/event source yet, but we need to display changes in state (door lock closed manually, user switched lights off and etc) - UI should be updated accordingly. The only way for now is to do polling - with the Taxonomy we can do very efficient polling.

So in the scope of this bug I want to try idea with Watchers that could accept any number of getter and poll all of them at once.

Likely this experiment will rely on #107