shadow53 / student-queue Goto Github PK

I had a thought: I have to do an amount of parsing the URL client-side in the HTML files in order to make things link up and work correctly. If I were to instead make a JavaScript template that takes a couple of parameters for each page, I could just put the values I need directly in there without doing any client-side parsing. This may or may not make things easier - I'll have to see. Leaving this here so in remember later though

JavaScript isn't exactly known for being a secure language. There isn't necessarily much secure information to intercept, but that doesn't mean that the program shouldn't be as secure as reasonably possible.

With this in mind, perhaps I should look into rewriting the backend in another language - which would mean reimplementing the websockets on the frontend as well. Given that this program is currently running on my own server hosted by A Small Orange, compatible languages are:

• PHP
  • Two possible websocket solutions are Ratchet and PHPWebSockets
• Ruby on Rails
  • https://github.com/websocket-rails/websocket-rails - supports Phusion Passenger, what ASO uses
  • https://github.com/igrigorik/em-websocket - well-recommended on Stack Overflow
• Python/Django/Flask
  • Would have to decide between Django and Flask
  • Both have support for websockets

Things I should also keep in mind:

• I have a little amount of experience in PHP and Python and none in Ruby
  • Though Ruby I hear is easy to learn and understand

Just a reminder. Currently running Solus Linux and they have Postgres in the repos but not MySQL or MariaDB. So to test on localhost, will need a Postgres backend. Good for testing the issue with listing them as optional dependencies.

Making a note to myself that I should add the ability to force HTTPS connections if there is a compatible SSL certificate.

According to the NPM docs, it seems like a peerDependency is one that is optional but recommended to have. Adding the backend wrappers to this would make it so that the end user can choose which one they are using rather than have one forced upon them.

Yup. Tests are a terrific thing that this project does not yet have. It should, because there have been a couple of times I thought I had everything fixed and, well, I did not :/

Looking at the NPM docs, any testing frameworks should be put in the devDependencies key in package.json, so that they are not brought in when it is being used as part of a larger project.

I've looked a little at Mocha and Chai, as well as Chai-As-Promised to add Promise support to Chai.

Ran into an issue where my server running https would fail to connect while localhost would connect fine, finally figured out it was due to loading websockets over WSS. It appears to be an issue in Firefox only, as Chromium seems to load and work fine.

The related Mozilla Bugzilla issue is 1187666. The apparent solution is to load the websocket application directly (not sure if this applies) and accept the certificate. This is a valid certificate on this site however, and Firefox does not throw any invalid certificate errors on other pages, so unless websockets use the default ssl certificate (The shared server's one, which is not in my hostname) instead of the one installed to the site, this should not be happening.

Perhaps fixing issue #1 will fix this issue as well. Until then, HTTPS will need to use Chrome(ium) or maybe IE, or load with HTTP.

This could pop up a chat box of sorts and allow the teacher to send a reply message to the student. Need to get more important things in place, but could be a cool addition.

Basically, if I refresh the teacher or admin pages, I have to type the password in again. I know nothing of setting cookies or the like, but perhaps there would be a way of providing authentication cookies for that particular page.

Plus: if the cookie for the queue admin page authenticates you for the teacher page as well, but not the other way around.

Should add something to the student request page so that they know where they are in the queue in real time - so they move from 5th to 4th when a request ahead of them is removed from the list.

Like the title says - mysql uses database while mariadb uses db. The difference should be abstracted to the plugins so that the same config format can be passed in to student-queue and the plugin takes care of modifying the config object for the database connection to use.

I'm pretty sure this is due to running the Gtk Firefox on KDE Plasma 5, as other Gtk apps have weird styling issues too. Still, the style should be smart enough to override bad defaults like this and make inputs visible.

Given that the intent behind this application is a real-time way to have students request help on in-class assignments, should there be an option included to have the requests archived? What use would this be to teachers?

I suppose it would be useful to have for teachers who have students who struggle a lot in class and want a record of what problems the student has had.

Forgot to include this while including the JQuery UI files. Might need to recreate the theme and redownload it

Just a really quick fix: Add some margin to the buttons

After looking more at expressjs request/response, I don't know why I was implementing so much in sockets that would be better as GET/POST requests. Therefore, basically everything but adding/removing help requests - so logging in and anything on an admin page - should be done with request/response, whether through forms or $.ajax().

Just that. I should either remove the whole bathroom thing entirely - and probably redesign the teacher page along with that - or add the functionality back in. Honestly, the feature hardly seemed to be used though.

Could always have the bathroom option be sent like a normal request, but be built from a template or something and have it styled differently in the list on the teacher page.

Testing the new code changes, the server crashes in app.js:222 because the queue was creating with a name capitalized but then the code uses it lowercased, which comes out as undefined. So some regularity in that would be useful.

The dialog box has multiple buttons, one placed by HTML ("Authorize") and the other by jQuery UI ("Login"). I need to get rid of one of these and, if I keep the Login button, make it try to log in. Right now it does nothing.

Basically adding a configuration page where the teacher can set options in the future, once different options are available.

Like the title says. I've implemented a basic home page that allows students to type in the name of a queue and it will try to take them there. It is badly written in that it does no error checking of any kind and, when submitting an empty input field multiple times, you can get something like: http://localhost:3000/////////////////

However I am not sure where to take this and I want to get a home page out there on this next release, so it will have to work for now. I will leave this issue open for further edits.

Gotta make a null check to use an empty string instead

This could be included as part of the configuration for each queue, on the configuration page. Something like radio buttons to enable the option as well as the normal two password fields to set it.

When the user submits bad data, invalid password, goes to an invalid page, or does something that returns a 40x or 50x HTTP status code, either nothing shows up or the page displays something like:

Cannot METHOD /path.

There should be pages that handle the most common 40x and 50x codes and will be sent to the user instead of just the status code and automatically handle things as necessary, either through automatic redirection or giving a link(s) to click.

If at all possible, any invalid GET request should return a "page not found" page instead of just "Cannot GET /path". I am not sure how well this will work with the dynamic modifying of paths, however.

Because this is all JavaScript, a student could theoretically be able to set up a new socket.on() that listens for events meant for teachers or even emit events that send them to the top of the list. Better safe than sorry, anyhow.

If I add a queue "test" and then delete it, I am still able to interact with it and load pages, but the table has been deleted along with its entry in the 'queues' table. Restarting the server fixes this as the Socket.IO room for it is never created.

Use this for removing a namespace: http://stackoverflow.com/questions/26400595/socket-io-how-do-i-remove-a-namespace

Basically, if no queues exist then the default "tab" should be the "Add New Queue" one. There's nothing to manage if none exist and having a user make that extra click is kinda stupid.

If database permissions are not set up correctly, causing the db.createConfigTable() function to fail, the server still attempts to load the server. The site home page loads, but nothing else does.

If there is a database error, it should display the database error or at least the fact that there was an error - probably using the ErrorPage constructor.

This will have to be addressed when I figure out cookies most likely, but if I can implement a login system for students - even Google/Facebook login - then I can do more cool stuff involving listing who is connected to the server for teachers, autofilling name field in the help request page, and more personalization for students.

Now that most of the features are in place for a basic queue system, the next logical step is to consider scaling outward by allowing one installation to hold multiple queues. There are a few things to be done first to make this attainable:

• Create a configuration page - perhaps a global and a per-queue page.
• Implement a better way of keeping track of existing requests - perhaps using MongoDB or a similar database. While I'm at it, it would be smart to keep track of which requests were given in what order so that the server can accurately inform the students of what position they are in the list.