We have some very exciting big updates we’d like to share!
We Decided to Make a “Web App”!
We’ve been thinking about this for weeks – to make an app, or to make a website? Apps would provide better and more consistent user experience, but also harder to build and update. And in the meantime – would the attendees take the efforts to download another app? A website seems easier to access, and easier to build – you don’t need to deal with building and publishing on several different platforms. But are they interactive enough?
Now we have a decision. The team thought about this a lot and talked with our client about it. We list our pros and cons.
After talking with our client, we agreed to build a web app, because guests don’t have to download anything and they can scan the QR code or type the URL to visit our site. For us, it’s easier to develop, test, and deploy for both iOS and Android compared to developing a native app.
- No extra download
- Attendees will download Eventbrite for ticketing and some detail information
- Easy to access via URL or QR code
- All attendees will have their own name tag, where we can put a pre-generated QR code
- Relatively easy to develop, test, deploy and maintain
- Compare to developing a native app for both iOS and Android
And since we’re building a web app. We are using React and Firebase.
React is a library for building interactive interface, which allows us to write customized UI components that match our design.
Firebase is a development platform that provides backend services, It provides powerful functionalities like authentication, storage, database, cloud messaging, and hoisting. which helps us develop an app quickly.
About log in
We decided to keep both “QR code” sign in, and the traditional “email/password” login.
In our design, the users can log in using either their email/password or by scanning the QR code printed on their badge. We’ll insert attendee’s information into the QR code so they don’t need to provide their email address again, they will be automatically logged in when they scan it.
Last week during quarters around, some faculty brought up a concern – what if the system got hacked? It would be unsafe to store their password.
The team thinks this is a serious issue, and talked about this for a long time. But we are not experts on web security. So we asked Steve, the person in charge of tech at ETC. He knows a lot about this.
Here is his reply:
As far as storing passwords go: if the concern is that someone could get into the team’s server and extract the password, that’s not much of a concern if you do it the proper way, which is that you only store the computed hash value of the password, not the password itself. This is standard practice. All you have to do when someone logs in is take the password passed to the system, compute its hash, and then compare it to the stored hash. If it matches, you let them in. It is mathematically infeasible to create two different passwords that result in the same hash (that’s called a Collision).
However, if the password is too short (< 14 chars, considered the current safe minimum for simple, alphanumeric passwords) then it’s possible for a hacker that steals your hashes to use a Rainbow Table to look up the pre-computed, corresponding password for a hash. This is why responsible website devs will add what is called a Salt to the hash, to pad it up to the minreq *and* to make sure it not the same as the hash for the bare password /because/ a lot of people use the same password for different sites. So if someone stole the hashes and looked up the password in a rainbow table it could be used to log them into other accounts with that username, like Facebook or Twitter. With salt, it won’t match even if the end-user is stupid enough to do that.
We are using Firebase, and it will do the hashing for us. So we think it’s safe for us to use a password, as long as we ban the passwords that are too simple. Giving this option can help attendees who are not familiar with QR code, or don’t have one (if they register onsite) get access to our web app.
Branding
Thanks to Ashley, we have our own logo, team photo, and posters now!
Don’t they look amazing?
Comments are closed