smunfr / sse-platform Goto Github PK

test framework needs to be compatible with travis

digitally sign and verify module's socket messages to avoid connections from attackers dressing themselves as a module

due to CORS, we cannot simply call the platforms logout handler from a module page. instead a module should implement an own logout handler and message the platform that a user logs out so that the platform can also clear his token.

Server needs to enable Cross Origin Requests in Header for Ajax Call

all of this module execution stuff is starting to get out of hand. there is no way this can be controlled in a stable way. we need to let every module be running independently and only communicating with the platform via the socket. everything else is there own business.

this way we also have more flexibility in module development because now basically everything can be a module in every programming language you want, as long as it implements the websocket connection.

cookie wont be set from localhost domain on chromium, needs hotfix

Add the module_name to the config.json file and to the global_vars.py since you need to replace the name 4 times in the socket_client.py and 2 times in the log within the main.py ("module has been recognized by platform") of the client.

When a user registers, a valid access token is also returned, use this to redirect the user to the main page (just as login does)

user has to be able to create an account and log in through a form.
save user in a db (security!)
save session of the user in a secure cookie afterwards.
and protect sensible requests (download/delete/start/stop of modules) only for authenticated users.

further implementations with dependencies:

• user must be an admin to do the stuff listed above (needs ACL mechanism)

when calling /execution/start, the module might be already running, in that case: include the port in the response, otherwise user doesnt know where it runs.

modules in production hide behind an nginx reverse proxy, need to be able to supply the URI's via config and not hardcode everytime

when starting a module, the platform needs to go through the module's dependencies/requirements and install them

Platform gives the path and file...

easy to fix in apply config
to so

with open(config) as json_file:
     data = json.load(json_file)

If a user works on a module for some time and does not visit the platform again, its token will remain active on the module but will be deleted on the platform, causing an inconsistent state.

if the modules directory is not available, some handlers will crash, because they assume the folder exists.

if the user is an admin account render a separate html page where it is possible to interact with modules

normal user accounts should only see a button to go to the module

Either directly from github (if API allows, needs to be checked) or from other central repository (would need to be set up)

since we have to pass the access token as a query parameter, it will fall under url encoding.
access tokens are 32 random bytes, if there is e.g. a "+" in it, it will be parsed as a space instead, which results in the token validation failing.

either find a way to disable the url encoding so that the string is read as it is,
or parse out the special characters from the access token

@pauzii just fyi, if your auth fails, try again until u have an access token that has no special characters

travis should automatically:
-run tests
-run build
-build docs
-on commit to master or on release: redeploy to (production) server

browsers will authenticate by cookie (access_token saved in cookie, validation for TTL is still in place) and app will auth with access token in Authorization Header

the module's static files (js, css) result in 404 - Not Found, therefore the module is not working correctly.

Login/Auth needs ACL to ensure user has sufficient permission do to certian actions

logout handler should invalidate the access token to require an new login

Moin, das erzeugt bei mir immer einen Fehlstart, weil ja die Plattform selbst keine Conifg hat (bisher). Also entweder config rein, oder sys raus :)...

on server startup create and admin account with credentials read from config.
depends on the access control to be implemented, so we distinguish requests between user and admin permission. i.e. certain resources should be admin only, while others can be accessed by users.