Jukeboksi: Jukeboksi moved page User:Juboxi/Chat Gallery/26.06.2004 with TimStarling to User:Jukeboksi/Chat Gallery/26.06.2004 with TimStarling: Automatically moved page while renaming the user "Juboxi" to "Jukeboksi"

2017-07-06T15:23:19Z

Jukeboksi moved page User:Juboxi/Chat Gallery/26.06.2004 with TimStarling to User:Jukeboksi/Chat Gallery/26.06.2004 with TimStarling: Automatically moved page while renaming the user "Juboxi" to "Jukeboksi"

← Older revision		Revision as of 15:23, 6 July 2017
(No difference)

Jukeboksi: Juboxi moved page User:Juxo/Chat Gallery/26.06.2004 with TimStarling to User:Juboxi/Chat Gallery/26.06.2004 with TimStarling: Automatically moved page while renaming the user "Juxo" to "Juboxi"

2013-06-14T13:04:00Z

Juboxi moved page User:Juxo/Chat Gallery/26.06.2004 with TimStarling to User:Juboxi/Chat Gallery/26.06.2004 with TimStarling: Automatically moved page while renaming the user "Juxo" to "Juboxi"

← Older revision		Revision as of 13:04, 14 June 2013
(No difference)

Jukeboksi: on shared user-tables and more user types

2004-06-26T10:18:51Z

on shared user-tables and more user types

New page

juxho> hi tim
 juxho> and thanks once again for the [[w:PHP|PHP]] tutorial
 TimStarling> hi
 TimStarling> no problem
 juxho> now I'm able to read [[Export-import|SpecialExport.php]] and [[Export-import|SpecialImport.php]]
 TimStarling> that's good
 juxho> we are going to work on those since they are so crucial to our multi-wiki setup but of little interest to wikipedia folk
 juxho> i've been wondering about "sharing" the user table between multiple wikis
 TimStarling> yeah, I've thought about that sort of thing before
 juxho> i know that a database is always distinct from other databases, but i've heard some people pondering about this for wikipedia
 juxho> any ideas on how it would be simplest to implement
 TimStarling> in mysql you can actually use database selectors
 juxho> selectors?
 TimStarling> so you could have a $userTable variable
 TimStarling> set it to "common.user"
 juxho> in php or mysql?
 TimStarling> in PHP
 TimStarling> the idea is to create a common database, and then replace all instances of the "user" table name with some other name
 juxho> so separate the user-table to a distinct database?
 TimStarling> yes
 juxho> that would require hacking [[MediaWiki]]
 juxho> we really don't want to [[fork off]]
 TimStarling> you can reference a table from a different database using dbname.tablename
 TimStarling> well, you don't need to [[fork]] as long as you do it right
 TimStarling> make it flexible, make it compatible with all existing wikis
 juxho> well what is needed is db read and also db write hacking
 juxho> our top priorities for hacks are:
 juxho> 1) http://develop.consumerium.org/wiki/index.php/Export-import
 juxho> 2) [[MediaWiki modifications|Shared login]]
 juxho> 3) [[MediaWiki modifications|More user types]] (besides sysop, bureaucrat and developer) with color coding in HTML
 TimStarling> interesting
 juxho> 3) eg. "Verified User" that is shown in Green
 juxho> thus we have a RGB scheme
 TimStarling> ok
 TimStarling> for shared logins, one possibility would be to have a function which converts old table names to new table names
 juxho> we want to implement all these so that they are included as optional code (defaulting off) in MediaWiki
 juxho> hmm
 TimStarling> so you could have wfTableName("user"), and that would return something dependent on settings
 TimStarling> it's good that you want to work on MediaWiki itself rather than fork
 juxho> but that increases the need for distinct db connections quite much?
 juxho> yes
 TimStarling> the only reason you need more than one DB connection is if you have more than one database machine
 TimStarling> well, almost the only reason
 juxho> i just wrote in reply to [[142.177.X.X|142]] for the upteenth time that i really want a separate [[Opinion Wiki]] simply because we can aggregate data ([[vote]]s on [[campaigns]] etc.) via [[w:SQL|SQL]] queries so we don't need to mess up [[MediaWiki]]
 TimStarling> have you seen my [[board vote code]]?
 juxho> no. i've just voted in the election and i really liked the idea of using public key crypto to enable audit trail
 juxho> it's marvellous
 juxho> i've been randomly thinking that we might have use for the board vote code in consumerium
 juxho> i really must congratulate you on the principle of board vote
 TimStarling> I wrote it in a hurry for the specific purpose of the board vote, but it shouldn't be too hard to make it more general
 TimStarling> thanks
 juxho> i'm very critical of submitting everything to computers because that gives technocrats too much (secret) power
 juxho> but in this case there is no prob since the private key could be on a disk in a safe
 TimStarling> yes, I wanted to make it so that it was hard for a [[developer]] to [[Wikimedia corruption|rig]]
 TimStarling> since a developer was one of the candidates
 TimStarling> and he came very close to winning, too
 juxho> once again my hat is off for the way you've implemented it
 TimStarling> it's also made so that's it's fairly difficult for a developer to work out who is voting for whom
 TimStarling> they'd have to constantly run a monitoring program on the server, which is detectable
 TimStarling> instead of just get in, grab the results and cover their tracks
 juxho> what do the individual records look like in plaintext then?
 juxho> how hard it will be to adapt the code to support many "elections" running simultaneously?
 TimStarling> the plain text records have three lines
 TimStarling> two for the two different positions, and one for "salt"
 juxho> salt is just random number?
 TimStarling> Contributing: Erik, Shizhao
 TimStarling> Volunteer: Angela, Michael Snow
 TimStarling> Salt: oirupq5438yqvjvha985yfqpqthlkaj3viuytbe0347f5yn4ifuhtjht3098t7qyn
 TimStarling> although it turns out the salt is redundant
 TimStarling> the GPG algorithm adds its own salt
 TimStarling> since the plain text records don't contain the usernames, it's not trivial for even the private key holder to determine who voted for who
 TimStarling> assuming the private key holder doesn't have access to the full DB, which is how we set it up
 juxho> so the DB hides the order in which votes were cast or what?
 TimStarling> the way we set it up actually had a slight flaw in this respect, but it's not too bad
 TimStarling> my original intention was to allow the private key holder to view whatever they want
 TimStarling> anyway, the web interface gives two different data displays
 TimStarling> the "list", where names and timestamps are displayed
 TimStarling> also, an election administrator may use this list to strike out invalid votes
 juxho> i noticed that
 TimStarling> and the "dump", which lists the encrypted records in chronological order
 TimStarling> so there's a few ways an election administrator could match up dump entries with list entries
 juxho> but that makes it possible to match records in "dump" with timestamps?
 juxho> you were too quick
 TimStarling> yes, it would be better if they were shuffled
 juxho> btw. do you object to me publishing log of this chat on consumerium.org?
 TimStarling> also, if an election administrator has the private key, they could find out which entry belongs to which person by striking it out temporarily, and seeing which dump entry disappears
 TimStarling> no I don't mind
 juxho> ok. i had to ask. i'd never publish any logs without permission from all
 TimStarling> so the way to get around that vulnerability is to make the private key holder a non-administrator
 TimStarling> I appreciate that
 juxho> what do you figure of adding another color for users that depends on user_rights? where would the code for such be best placed?
 TimStarling> it depends on where you want the colours to show up
 TimStarling> on all links to the user page?
 juxho> let me think
 juxho> RC
 TimStarling> well, the code for [[Special:RecentChanges|RC]] is in Skin.php
 juxho> all signatures, yes
 TimStarling> ok, if you want it to be all signatures, the easiest thing to do would probably be to change the link colour in makeKnownLinkObj
 TimStarling> that's in Skin.php
 TimStarling> you'd just check if the link is from the user namespace, and colour it accordingly
 TimStarling> I'm not sure that it's secure though
 juxho> so load all the user_rights to a array or hashtable and use that to set the color?
 TimStarling> you could probably use font tags or style attributes to override it
 TimStarling> yes
 TimStarling> to make it more secure, perhaps you could change the title attribute
 TimStarling> that's what comes up when you hover the mouse over a link
 juxho> you mean that <nowiki><a href="User:Juxo">Juxo</a></nowiki> to fool that i'm verified?
 TimStarling> yeah
 juxho> good point

User:Jukeboksi/Chat Gallery/26.06.2004 with TimStarling - Revision history

Jukeboksi: Jukeboksi moved page User:Juboxi/Chat Gallery/26.06.2004 with TimStarling to User:Jukeboksi/Chat Gallery/26.06.2004 with TimStarling: Automatically moved page while renaming the user "Juboxi" to "Jukeboksi"

Jukeboksi: Juboxi moved page User:Juxo/Chat Gallery/26.06.2004 with TimStarling to User:Juboxi/Chat Gallery/26.06.2004 with TimStarling: Automatically moved page while renaming the user "Juxo" to "Juboxi"

Jukeboksi: on shared user-tables and more user types