Re: GSoC: Adding a web interface similar to the Hydra web interface

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 3092 bytes --]

Hi Tatiana,

On Wed, 13 Jun 2018 01:43:31 +0300
Tatiana Sholokhova <tanja201396@gmail.com> wrote:

> I've just fixed codestyle issues and replaced HTML5 preamble with XHTML.

Yeah, looks much more regular now.

> I adopted the static file serving procedure from code shared by Ricardo.
> 
> https://github.com/BIMSBbioinfo/rcas-web/blob/22a114a0f281845117ed0ab105267f132fc525e4/rcas/web/render.scm#L68

I understand.

It's common to do stuff like that - but it's just an unnecessary risk.

Especially since we have cuirass build (and presumably sign) everything for us,
it would be very very bad for an attacker to be able to read out the private key
used to sign everything.

Blacklists are a whack-a-mole approach (maintaining it will never end) - and in
this case nothing in POSIX states that these characters are the only
problematic ones (and I know of quite a few filesystems where there are a lot
more problematic strings).

Much better to have a whitelist.

> I am considering the following possible implementation of a whitelist. We
> can create association list with allowed file names and their mime types (to
> replace file-mime-type list). What do you think about it?

Yes, that would be a simple way - and easily maintainable, too.  Let's do it
like that.

> Now we have the only one parameter of the request
> which is related to pagination. It is the page number. Should we add more
> parameters to the request in order to request evaluations with specific
> timestamps and IDs? Or there is some other way of doing that?

I don't think we would need the parameter for the page number anymore.

I think we should add a parameter like "boundary" or something
(or multiple ones - I defer to your judgement).

It would also be possible to use "boundary=a&boundary=b" (note: same name).
Not sure whether that would be obtuse or not.

From a technical standpoint it doesn't matter - you just have to have get a
tuple of data cells (of the last row) into the query string somehow.
Also, it has to be able to be entirely optional (in order to get the first page).

The tuple of data cells should uniquely identify one row in the result.  (If it
didn't, you'd skip the other same-value rows when going to the next page)

(There would be an alternative possible to be able to dispense of this
requirement, but I think it would be too obtuse to maintain)

For the evaluations, the relevant data cells would be (starttime, id,
revision) or so.

I suggest adding starttime to the "Evaluations" database table to
improve usability.

(If we wanted to eventually provide a way for the user to sort columns,
we'd have to also adapt what columns this cell list contains - although
it doesn't make sense to stay on page 243 when you change the sort order :) )

What do you think?

> I have
> checked the Hydra pagination request structure. It uses the same form of
> the request path for pagination buttons that we have now:
> "?page=<page-id>".

Yeah, the practice is widespread.  Let's do better than that if we can.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]