Add support for overriding QR code host name/IP address

[jawaad-ahmad]

Prior to the 2016 competition, all 40+ QR codes were printed and mounted with the wrong IP address. When this was discovered, the QR code had to be re-printed and re-mounted all over the course.

Recommend adding some equivalent of Tools > Options to the BRATA GUI to allow entry of a last-minute IP address override. If necessary, the competition day presentation can be updated to mention the last-minute change, and the speaker can guide all the teams to go into the options and set this field to the correct IP address.

When each QR code is scanned by the phone, BRATA can automatically replace the hostname portion of the URL with the configured value if it is set.

[sminster]

Maybe we should just register a domain name and use that in the QR code URLs. Or convince EIT to give us something like sdc.harris.com.

[ellerychan]

I like the idea of putting a mechanism in the BRATA that allows the MS address to be configured/overridden. It would help during testing and development, and could overcome some competition day problems.

On 4/27/2016 5:29 AM, Scott Minster wrote:

Maybe we should just register a domain name and use that in the QR code URLs. Or convince EIT to give us something like sdc.harris.com.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/brata-hsdc/brata/issues/109#issuecomment-215025928

---

This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

[jawaad-ahmad]

The domain name idea came up. I think that's what led to this issue. Agreed that's another good way to go but Ellery makes a good point this issue would be useful for testing. I can see this useful if we have multiple MSes available to hit. We won't need to print up multiple sets of QR codes and keep them straight. One set all pointing to 10.0.0.1 would be sufficient for testing on our integration days.

[jaron42]

The issue with domain names is the changes take some time to replicate. If we did a domain name I would suggest the domain be exposed more as a discovery service. That way we are in control of the timing of the service changing the actual endpoint. That said perhaps we should not reinvent the wheel and consider being a SOA we should use a real discovery service solution. Unfortunately most I found in a quick search are Java or Go if stable, although there are a half a dozen beta looking discovery services that are python based. either way it might be nice to have a specific QR code that as suggested sets all overwrites all the future host calls, I have to see if we can make it fit, but maybe even use one of the displays on the MS to generate it. The only other fear I have of using a domain name is we would like to start planning in how to grow this out for other areas to run, so we would need to host that for them as we want to keep any expansion cost to as minimal as possible.

[ellerychan]

I'm not sure I clearly understand the differences between various suggestions from @jaron42, @jawaad-ahmad, and @sminster.

I thought the root of the idea that @jawaad-ahmad was suggesting was a very low-level mechanism that would be added to the BRATA. It would transform a URL using a substring match and replace. The transformation would be applied to every URL that leaves the BRATA.

It could be configured in the BRATA GUI by a pair of text fields, in its simplest form. This would allow URLs to be retargeted to a test server during development, or to the primary MS on competition day, or to an alternate server if necessary.

Beyond the simple mechanism, we could allow it to be configured by a magic URL. On competition day we could have all teams point their BRATAs at a QR code on the big screen up front to configure the URLs.

Other extensions: We could allow more than one match. We could allow the matching patterns to be regular expressions.

If we could do arbitrary remapping, we could make a URL that looks like this:

http://DOCK01/submit

and remaps to this:

http://ms01/station/DOCK01/action/SUBMIT/team/<regcode>/

I don't know anything about SOA. I know what I'm suggesting is completely ad hoc, so maybe there is a better way. What I like about this approach is that the low-level mechanism is very simple and can be manually configured if necessary, but could also be configured by an automated mechanism. It is independent of whether we get an official domain name, but can support it, or work around it even if it changes on competition day.

[jawaad-ahmad]

It looks like we have plenty of good ideas in this thread already. My vote would be to implement the basic low- level text fields first under this issue. All the other ideas discussed can, then, extend into separate dedicated issues to be worked as needed.

So far I'm reading the following as possible separate issues:

Support a domain name (i.e. Register a domain name) Set up a discovery service Support the endpoint configuration for this issue via a magic QR code

Did I miss anything?

[deleted extra stuff included by email reply]

[jaron42]

So my vote for the simple first step is that the mapping be a data entry that replaces anything before the first "/" after "://". i.e. if the QR code returns a url of http://foo.bar.com/DOCK01/submit/ or other url as specified by the existing interface then becomes /DOCK01/submit/. We already hide the regcode in the JSON data so I don't know why other than making more work we would want to move it back into the url, so I would leave everything else alone. Just the front of it is replaced. I know I will regret saying this but the reason the entire front is given as security aware most of the team has been I am surprised no one suggested switching to https yet. So the plan to allow the entire initial server destination portion to be remapped is to handle the destination, port and protocol being changed while leaving the rest of the url signature behavior as is. I also agree start off with it as just text entry, but would like to see it baked in with the registration feature and isolated out of the student interface, as we did the passcode and regcode implementation this year.

[jawaad-ahmad]

That's not a bad idea. How about simply modifying BRATA to remember whatever host is specified in the registration QR code, and then replay that for each successive QR code until re-registering?

This way, we don't have to modify the BRATA GUI to support manually entering any URL, and we could still have some sort of back door available for testing (e.g. some configurable parameter).

If everyone uses the same registration QR code, then only that QR code would need to be reprinted.

For example, suppose the QR codes are originally printed as:

http://10.0.0.1/register
http://10.0.0.1/launch/startChallenge
http://10.0.0.1/launch/submit

This turns out to be wrong and we need to change the host. We also want to switch to https but port 443 is already in use, so we reprint just the registration QR code:

https://10.1.0.1:8443/register
http://10.0.0.1/launch/startChallenge
http://10.0.0.1/launch/submit

If using regular expressions, this should be only marginally more complex than what @jaron42 proposed above, and it should primarily be just the regular expression itself:

(^[A-Za-z]+\:\/\/[A-Za-z0-9.]+(\:[0-9]+)?)\/

When BRATA scans the registration QR code, it can parse and remember everything till the first slash following the protocol:

[https://10.1.0.1:8443] [/register]

When scanning the start challenge QR code, it can parse the same portion and prepend this before hitting the URL:

https://10.1.0.1:8443/launch/startChallenge
https://10.1.0.1:8443/launch/submit

This leaves the usual case of what to do when the team has walked all the way to the Launch course and their phone dies, they pull out their backup phone, and they want to resume. Should they have to come all the way back to the conference room to re-register the new phone manually?

[sminster]

I like the idea of communicating the base MS URL in the registration step. However, the string replacement seems overly complicated to me. What if the QR codes simply contained the trailing part of the URL, such as "/launch/startChallenge" or "/launch/submit". Then the BRATA could simply append that to the base URL (https://hsdc.harris.com:8443/2017 or whatever) to get the final URL to use.

Alternatively, it could be up to the students to keep track of that base URL in the registratrion step and do the string concatenation themselves.

[jawaad-ahmad]

I wasn't aware QR codes can contain non-URL arbitrary text. Agreed Scott's idea would be a simpler implementation.

Updated QR codes from the example above:

Reg URL 1: http://10.0.0.1/register -> [http://10.0.0.1] [/register]
Reg URL 2: https://10.1.0.1:8443/register -> [https://10.1.0.1:8443] [/register]
/launch/startChallenge
/launch/submit

Still need the same regular expression as above--assuming it's correct--to parse the registration URL.