emilbechmadsen / ssas Goto Github PK

There are several places where aren't using transactions, where we should be. This is especially true in the User model.

So they don't flood the database. I suggest 500.

Right now they aren't links.

At the moment, errors are presented with ugly, non-HTML error messages if something goes wrong, and sometimes they aren't notified at all (like when they try to login with bad information).

This should be improved, possibly by implementing a generic error page where an error message can be set through a request.

When information comes in from the database, it should be validated, and an exception should be thrown if the data is invalid.

Example: A test that tries a replay attack.

At the moment, Raptor Dating uses the root user for database access. For some reason it fails with the ssas user. This should be fixed.

Since we know the service we will be integrating with will have a specific IP address, we should restrict access using a API key to a IP address.

This means:

• Adding IP column to api_key in database
• Checking against this IP in ApiService

We should expose an API at /api.
It should have the following services:

• /api/user/search POST
• /api/user/{id} GET

Right now, any page can only have one type of header. However, the type of header should be determined by the user's status (logged in/out), and not the page.

At the moment, the User model produces an exception. The correct behavior is to not add the hobby, and not throw and exception.

We should list the attacks we protect against on the front page. These include:

• Session stealing (SSL)
• XSRF (formkeys)
• Replay attacks (formkeys)
• XSS (sanitizing/validation)

We should HTML encode everything we get from the user model, in case someone sneaked HTML/Javascript in there.

Otherwise, hugs are displayed in an unintuitive order.

Currently, the log is only printed to the console. It should also be written to a file.

They should be able to.

An admin should have an admin button in the header that takes them to the admin page.

At the moment, Raptor Dating is run as one of our users, from a home directory. It should reside in a directory all our users have access to, and be run as a less privileged user.

We should then hook the deployment up with sbt, so we can simple write sbt deploy to run the new version.

The site fails when trying to create a user with Æ Ø Å and so on. We now the model and database layer handle these (through the unit tests), so it must be in the spray layer.

Currently, the same session id is used both before and after login. This means that on a public computer, one could note the session id, then wait for someone to log in. Since the same id is used, one could now use the session id to act as the logged in user.

To remedy this, the session id should be change when logging in.

We need to log our uptime somehow,

So they can't flood the database.

I suggest 100 hugs per user. We simply delete the old hugs.

Users should be able to 'hug' each other. This means:

• Adding a 'hug' relation to the database
• Adding a 'hug' button when viewing other users' profile pages
• Adding a view (possibly on a user's own profile page) where they can view hugs.

Currently, pages vary wildly. They should be wrapped in a div with id="page" or something similar, so we can easily style them.

I suggest after 24 hours.

This means adding text to the confirmation mail about this, as well as adding the cleaning to the DbWorker.

At the moment, formkeys are sent as hidden fields in all forms. In theory, these would be visible to any injected Javascript on a page. It might be better to send the formkeys as HTTP-only cookies, as these shouldn't be visible to Javascript.

Currently, when a user visits the site, their soul is instantly destroyed by the design. This should be remedied.

Maybe Twitter Bootstrap?

We have to use another groups API to show users.