From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: GSoC: Adding a web interface similar to the Hydra web interface Date: Wed, 13 Jun 2018 10:27:12 +0200 Message-ID: <20180613102712.2c46d7d5@scratchpost.org> References: <87d0xyn9zs.fsf@elephly.net> <87d0xswvls.fsf@elephly.net> <87r2m4ntk4.fsf@mdc-berlin.de> <87tvqxy4i9.fsf@elephly.net> <87in78hxo2.fsf@elephly.net> <878t7xb58o.fsf@elephly.net> <874lijbqvf.fsf@elephly.net> <20180606200210.7a9c4dd6@scratchpost.org> <20180612183504.2621cefa@scratchpost.org> <8736xrd64y.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/yV86Yt37=pMfJmYR2sWHaBG"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fT17v-0007bp-Mm for guix-devel@gnu.org; Wed, 13 Jun 2018 04:27:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fT17r-0001UB-Mq for guix-devel@gnu.org; Wed, 13 Jun 2018 04:27:35 -0400 Received: from dd26836.kasserver.com ([85.13.145.193]:45582) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fT17r-0001T6-BG for guix-devel@gnu.org; Wed, 13 Jun 2018 04:27:31 -0400 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Tatiana Sholokhova Cc: guix-devel --Sig_/yV86Yt37=pMfJmYR2sWHaBG Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Tatiana, On Wed, 13 Jun 2018 01:43:31 +0300 Tatiana Sholokhova 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. >=20 > https://github.com/BIMSBbioinfo/rcas-web/blob/22a114a0f281845117ed0ab1052= 67f132fc525e4/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 privat= e key used to sign everything. Blacklists are a whack-a-mole approach (maintaining it will never end) - an= d 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 l= ot 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=3Da&boundary=3Db" (note: same na= me). Not sure whether that would be obtuse or not. =46rom 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. (I= f 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=3D". Yeah, the practice is widespread. Let's do better than that if we can. --Sig_/yV86Yt37=pMfJmYR2sWHaBG Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlsg1WAACgkQ5xo1VCww uqXxTgf/fp1LRMiWld8j7GkyrPbhFcgXn5w2yLLjjQPWAtiuRf2hQ5Tnig4W8q8v TSEpTRWVIp7hvd9RgPL94se1NtzBn/sVGSofuIJwjHDYPCYauUCayAcF1Yf6nt+/ S8ckx+D5feaQrxp34QBFwwka2fC1GPS0AiieHXyxhh99ub3/V+hZs8nMNvrr+SiE z6U1PiUnP2BxkI/1s8bDxmGbAr6fxDN5bXjDtK7WLHNpg7IrSrDIBfSL5lvKtMsA kMkFuOp9LRqDZLkQJ9F+nO8HnlwAu/SPZSOE3bn2AwqX6MGH0jEl4urYnLIyOe7l k926O2PuRd1e61JyUYPr4HoeYkmEUg== =kZDv -----END PGP SIGNATURE----- --Sig_/yV86Yt37=pMfJmYR2sWHaBG--