amiv-eth/amivapi

The REST API behind most of AMIV's web services.

amivapi's Issues

Apply permissions based on __owner__ and __affected_user__ to requests for GET, PUT, PATCH and DELETE

Implement rights to access GET, PUT, PATCH and DELETE for all ressources

Unit tests for Authentification

This should check at least:

• Can a user login(receives a token and it is correctly added to database)
• Do all kinds of passwords work as intended(unicode, chinese weird characters, shellcodes)
• Does a user get admin access (g.resource_admin_access) correctly based on his permissions and the requested resource(or because he is root)
• Is the correct user logged in (g.logged_in_user)
• Can a user change his password with PATCH
• Can a newly created user log in(does his password hash correctly?)
• Is the _author field correctly set for all items
• Does a GET request by an owner return the correct dataset
• Does a GET request by an owner return the correct dataset for an indirect owner(via relationship)
• Does a POST request by a future owner work
• Does a POST request by an indirect owner work

organize Forwards as external user

Root user and Anonymous user don't have _etag, _created and _updated

When the root and anonymous user are created they are created by insert statements which don't update metadata fields. This would be nice to have to be able to send requests to that item.

Revert actions

There should be a possibility to revert actions as DELETE and PATCH when they change information which may have taken a lot of work to do. This could be achived by archiving stuff or by versioning. Discussion?

Mailinglist backend

Changes to the forwards resource should propagate into the filesystem, where they are read by the mailserver. For every forward there should be a file ~/.forward+<address_to_forward>, which contains one address per line and can have comments prepended with '#'.
For example the list "[email protected]" with the addresses "[email protected]" and "[email protected]" should have a file ~/.forward+helfer with the contents:

# Maintained by amivapi, changes are overwritten

[email protected]
[email protected]

LDAP importer

Implement functionality to import users from LDAP and to update account information.

Organize write permissions to /users

• only admins can change more than RFID
• “extraordinary members” can change their stuff
• you can set your own password

Permissions should only accept existing roles

OP log

All requests should be logged including their query strings(except passwords). This should vastly improve bug detection.

Yes we scan.

Add a feature where a unittest can start with a predefined database state

A unittest should only test its own set of operation and not rely on necessary steps such as user creation before that, which could also fail. Therefore it should start with an already filled database. This hopefully makes it easier to see which part exactly is the problem.

Clean up setup procedure

Sort an clean all functions necessary to configure the api.

One single setup would be optimal.

Extract information of permission_matrix

It should be possible to get what roles exist and which permissions they grant via the API to display those informations to a user, when he is performing administrative tasks.

e-mail address schema validation

Add whitelisting for file type depending on resource

Different resources should need different whitelistists, e.g.

Joboffers:
logos: png, jpeg, ...
pdf: pdf (Duh.)

Make unittest baseclass for test cases with disabled authentification

There should be a simple baseclass, which unittests can use, when they should not require authentification.

Support for signup to sold-out event?

One might want to signup for an event which is already full, in case somebody cancels his/her signup.

Check for authorization when retrieving file from custom endpoint

The function in download.py will send a file from directory when the correct URL is accessed.

Currently, no authentification is necessary for this, I don't know how to implement it properly.

Create folder for file storage

I don't know where to create the folder. Ideas?

Documentation: File interface

Describe how the file interface can be used in the User Guide.
Also describe implementation details in the Developer Guide.

Studydocument file association

Associate files with studydocuments and update the association on changes to the studydocument. Remove the file when it is not needed anymore.

File resource can be created without file; breaks everything

It is possible to create the file resource without sending a file, but this will break all GET requests that try to access the resource.

What needs to be done

• file is required to create /files item!
• fix mediastorage anyway so it doesn't break

Add content to the report

• groupwork presentation
• images (random hacking shell images)

LDAP Synchronisation

There should be a feature, that accounts are updated from LDAP at regular intervalls. This needs a mechanism to schedule task to run at a regular interval(cron interface).

Document permissions

• Document /permissions resource
• Document permission system (root account, role based admin system, affected_user and owner system)

garbage_collector for expired permissions, confirms, etc.

Convert Doc-Files into one latex-document

API Version

The API should send a version string, which can be used to provide backwards compatibility when the API is changed.

Deleting things returns 400

When deleting anything which is referenced by a ForeignKey which can not be nulled, 400 will be returned. We need hooks which handle this before the action is performed.
Same problem for puts.

File upload

Make it possible to upload files to the /files resource, retrive the metainfo or the content

LDAP Login

Implement to reroute the login to LDAP and when credentials match there login the user without local password check.

signup for an event as external user

signup with user_id:-1 returns error 422 even if it is a public event and i provide an valid email-address

api returns password-hash for users

don't return password-fields in any case for anyone

API Documentation

A documentation of all resources with their methods, their fields and the possible value ranges should be available.

Document session management

• Create a tutorial how to login and send the token to authorize requests.
• Write API documentation of /sessions resource
• Document token, password hash method, security details

Exception Log

Log all exceptions with relevant information to fix bugs. The log should be informative enough to reproduce the situation where it occured.

Documentation: General Architecture

Describe in the Developer Guide what files we have and where to start to understand the code.

Data Relationships

Need to implement a correct mapping between different resources

• GET requests on e.g. /users should show groups
• POST/PUT on e.g. /groupmemberships should make a new mapping between an user and a group
• POST/PUT on /users doesn't assign any relationships
• DELETE on a user should also delete all relationships

Make PowerPoint Presentation

• Many Pictures
• Such Image
• Very Graphic
• No Text

Files can't be uploaded

The 'with' block in utils.parse_data() closes any files sent before they reach the point at which they are written to the disk.

This causes an I/O error.

Document introduction

Should include somehow:

• What is REST
• How to send requests
• Response format(meta fields)
• Pagination
• Where clauses
• etag

Advanced:

• Bulk insert
• Projection

Events have no images

Wrong arguments for POST to sessions should return 422

There is no parsing of arguments for logins yet

Do we want Multilanguage support?

Regarding or master students and general API viability, I would like to implement support for english and german.

This is a minor change in the model - does anything speak against it?

Validation schema for additional_fields in events

PUT requests don't get validated

Only callbacks for POST and PATCH are registered to call the check_ functions in event_hooks.py

People should only be able to self-enroll for a forward when it is public

Currently everybody can join any forward. There should be restricted forwards, which only owners or admins can add people to.

validate prices in /events

prices are stored as string because sqlalchemy does not support decimal-objects
Therefore they need to be validated by a schema

MySQL backend

The app will run on MySQL in production, so add support for it. Since we are already using SQLAlchemy for the data layer, adding MySQL support is as simple as switching the SQLALCHEMY_DATABASE_URI setting to a MySQL URI. The real issue is to support multiple instances running seperated from each other on the same database, e.g. when running the test suite on the developer machine (or even multiple test suites in parallel).

In short: Make sure the tests create their own (preferably random) database "on-the-fly".

Unit Tests for correct setup of API

The unit test should check whether the manage.py script correctly initializes config files and the database.