Emails and User Registration

In our project’s function specification, we said user registration would work though emails.

This would have worked in a manner we are all familiar with. User registering would need to confirm that a given email address was theirs by entering a code or clicking on a link they received via email. It was also envisaged that instructors when creating a class would enter a list of their students’ emails addresses.

Somethings are easier to describe than code. In order to write this system, we would have needed some kind of stub email system to make up for the fact that we don’t have easy access to smtp servers.

Accordingly, we have opted for a simpler system where students can register for a class by using a unique registration code. This simplifies development and registration and could always be supplemented by an email and/or system authentication plugins were development to proceed further.

Another change we have made was to rename the class "class" to "module". Class is a keyword in Python (and many other programming languages) and wasn’t going to work as class name.

Comments

Post a Comment

Popular posts from this blog

Image
 We are making good progress, we have all the "models" set-up, we have a basic user-interface, a basic User Account System. Users are able to view their modules, labs and exercises. Instructors are able to create and edit Modules etc. We started brainstorming a system that would allow a student to enrol into a module. We thought about ways of automating the process of registering a large amount of students. In this way the system would be similar to the actual Einstein system, in that, students wouldn't need to do anything themselves. We finally decided on creating a system similar to poodle or moodle, where a student would need a code, usually given by the lecturer, to enrol themselves in a module and view its contents.
Read more

Docker, Part I

Having opted for a project which entails having one Dockerised application run another, getting to grips with Docker an inevitability. The first item on the agenda was to get something resembling a production environment running inside a container. Instinctively I opted for doing with within a single container. I started by basing the container/image on Alpine Linux a popular light-weight distribution which uses Busybox. While we had originally proposed to use MySQL for our production database, a little research on the topic showed that the Django developers recommend PostgreSQL. (They express far fewer caveats about it at any rate). FROM alpine:3 # apache runs on port 80 by default EXPOSE 80 # install system packages RUN apk add --no-cache python3 py3-pip postgresql15 apache2 apache2-ctl \ apache2-mod-wsgi py3-psycopg2 Using Alpine also allows us to take advantage of its convenient package manager apk . Here where thing got a little sticky however as apk installs an older...
Read more