00:48.39 | *** join/#bzflag Detrimental (~james@h246.208.30.71.dynamic.ip.windstream.net) |
01:27.17 | blast007 | jeffm: I'm getting another VM prepped to experiment with |
01:27.32 | jeffm | cool |
02:07.07 | blast007 | jeffm: and this might be worth us checking out instead of my mvcish: http://kohanaframework.org/ |
02:07.40 | blast007 | though their docs are a bit.. lacking. Some of their documentation is just a page of links to other sites that don't work... |
02:07.45 | jeffm | what does the "H" stand for? |
02:08.24 | blast007 | what? |
02:08.54 | jeffm | HMVC |
02:09.14 | blast007 | ah, hmm.. dunno |
02:09.42 | jeffm | Hierarchical |
02:38.01 | *** join/#bzflag mdskpr (~mdskpr___@rh-cypressn-cs3-137-77.njit.edu) |
03:03.08 | *** join/#bzflag Guest922 (18b6f76d@gateway/web/freenode/ip.24.182.247.109) |
03:04.10 | *** join/#bzflag Guest146 (18b6f76d@gateway/web/freenode/ip.24.182.247.109) |
03:30.53 | *** join/#bzflag Drvibe (~Drvibe@CPE0026f32b2f88-CM0026f32b2f85.cpe.net.cable.rogers.com) |
03:30.58 | *** part/#bzflag Drvibe (~Drvibe@CPE0026f32b2f88-CM0026f32b2f85.cpe.net.cable.rogers.com) |
04:12.57 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
05:27.30 | *** join/#bzflag mdskpr_ (~mdskpr___@rh-cypressn-cs3-137-77.njit.edu) |
05:48.32 | *** join/#bzflag _afu_ (~sgendle@c-69-244-7-239.hsd1.al.comcast.net) |
07:00.01 | *** join/#bzflag mdskpr_ (~mdskpr___@rh-cypressn-cs3-137-77.njit.edu) |
07:13.56 | *** join/#bzflag Pimpinella (~frank@213.9.108.240) |
07:20.39 | *** join/#bzflag _afu_ (~afu@c-69-244-7-239.hsd1.al.comcast.net) |
07:26.21 | *** join/#bzflag _afu_ (~afu@c-69-244-7-239.hsd1.al.comcast.net) |
07:40.51 | *** join/#bzflag Marzipan (~Marzipan@sign-4d091f60.pool.mediaWays.net) |
08:31.17 | *** join/#bzflag swigg (~swigg@bzflag/player/Swigg) |
10:22.02 | *** join/#bzflag Admirarch (~Athelthra@mrush.mth.abdn.ac.uk) |
13:44.33 | *** join/#bzflag PrezKennedy (~DarkCalf@173.231.40.98) |
15:02.03 | *** join/#bzflag mdskpr__ (~mdskpr___@rh-cypressn-cs3-137-77.njit.edu) |
15:02.21 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
15:02.21 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
15:06.23 | *** join/#bzflag TyroneFHornigh (~dbw@108-197-33-160.lightspeed.sndgca.sbcglobal.net) |
15:22.21 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
15:25.42 | *** join/#bzflag Detrimental (~james@h121.235.17.98.dynamic.ip.windstream.net) |
15:48.54 | *** join/#bzflag L4m3r (~l4m3r@bzflag/developer/L4m3r) |
15:48.55 | *** mode/#bzflag [+v L4m3r] by ChanServ |
15:56.09 | *** join/#bzflag jeffm (~jeffm@cpe-76-167-236-199.socal.res.rr.com) |
15:56.09 | *** join/#bzflag jeffm (~jeffm@unaffiliated/jeffm2501) |
15:56.09 | *** mode/#bzflag [+v jeffm] by ChanServ |
16:27.06 | blast007 | jeffm: would it make sense to have all the front-end parts of the group manager and player registration/management as part of the main BZFlag site? |
16:27.27 | blast007 | as in, bzflag.org, not something.bzflag.org |
16:27.43 | jeffm | that could be possible |
16:28.16 | jeffm | there is no reason to not do it like that if there are no technical problems with it |
16:28.40 | blast007 | yeah, shouldn't be any issues doing it that way |
16:30.19 | blast007 | I should keep in mind what could need SSL though. |
16:30.58 | blast007 | anywhere we log in, which currently would be the player manager/registration (and weblogin), and the list |
16:31.13 | blast007 | s/currently // |
16:33.54 | *** join/#bzflag nielsle (~nielsle@3239149-cl69.boa.fiberby.dk) |
16:36.32 | jeffm | yep, that may be the only reason to put it on it's own but I don't know much about how certs are given out these days |
16:37.50 | blast007 | low end certs are pretty cheap.. like $10/year |
16:38.14 | blast007 | but still, if we can do it with one instead of two... :) |
16:40.05 | blast007 | one way to solve that would be to have the client hit bzflag.org for the list, and have a read-only copy of the servers table on that VM |
16:40.57 | blast007 | and then the token table (part of the user table or otherwise) would be writable on that VM, but a read-only copy on the VM that handles the servers - but there'd need to be some way to invalidate the token after it's used.. hmm |
16:43.08 | jeffm | a brb, gotta drive to work but have questions |
16:51.53 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
16:51.53 | *** mode/#bzflag [+v JeffM] by ChanServ |
16:52.35 | JeffM | hokay, so by "read only vm" do you mean the entire VM or that the vm has a read only synced copy of the database? |
16:52.50 | blast007 | a MySQL slave |
16:52.53 | JeffM | ok |
16:52.57 | JeffM | that makes more sense |
16:53.16 | JeffM | I was thinking "how do you make an entire VM read only" |
16:53.21 | blast007 | very carefully |
16:53.35 | JeffM | that'd be cool, because we could actualy have multiple slaves and have multiple end user endpoints |
16:53.51 | JeffM | have the main be www but put a couple others on client side failover |
16:54.05 | JeffM | then if things went down people could still list and still get tokens |
16:54.33 | blast007 | yeah. I'll need to sit down and think about what could (if the need arise) logically make sense to split out or load balance in the future |
16:54.48 | blast007 | and then plan for that kind of a split, but also design it to work in a single self-contained VM |
16:57.11 | JeffM | well we have an odd situation, normaly you'd think that the one servicing clients would get hit more often then the one servicing servers |
16:57.19 | JeffM | but we have more servers then players |
16:57.44 | JeffM | but still most of the servers only heartbeat |
16:58.02 | blast007 | even still, the server's query is more complicated than the client's |
16:58.15 | JeffM | true |
16:58.31 | blast007 | well, I guess there is a group check when the client asks for the list |
16:58.36 | JeffM | it's probalby not a bad place to split them |
16:58.43 | JeffM | yeah but no key check |
16:58.53 | JeffM | and no data stored |
16:59.00 | blast007 | token is stored |
16:59.00 | JeffM | well no that's wrong, the token |
16:59.07 | JeffM | yeah they may be very similar :) |
16:59.12 | blast007 | :) |
16:59.43 | blast007 | I'm sure that having us not have to swap between two databases several times per script execution would help as well.. |
16:59.52 | JeffM | yeah |
17:44.55 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
17:44.55 | *** mode/#bzflag [+o TimRiker] by ChanServ |
17:45.58 | JeffM | blast007, I'm not sure your plan would work, the token has to get from the server the client hits to the server bzfs checks, or did I misunderstand it? |
17:46.32 | JeffM | the only things that could be read only would be the server list table and the user tables |
17:46.39 | JeffM | the token table would need to be a normal cluster |
17:46.50 | blast007 | yeah, I mentioned that at the end |
17:47.19 | JeffM | can you do different read/write syncs on a per table basis? or just per database? |
17:47.39 | blast007 | I saw mention of multiple-master replication as well, but I'm not sure if that got added |
17:48.19 | JeffM | I really like the concept of splitting it up, if we got more players then servers again it would make a lot of sense |
17:48.26 | JeffM | except that pesky token thingy :) |
17:48.52 | JeffM | you could have the client say "i got my token from this server" |
17:49.02 | JeffM | and have the game server verify it from that endpoint |
17:49.21 | blast007 | yeah, I thought about that as well |
17:49.30 | blast007 | both ends would still need write access |
17:49.38 | JeffM | yeah but to different parts |
17:49.48 | blast007 | well, both to the token part |
17:49.50 | JeffM | the token stuff could be made external form the synced stuff |
17:49.51 | JeffM | yeah |
17:50.00 | JeffM | but then at least we'd have multiples |
17:50.17 | JeffM | and if bzfs can't get there, it tells the client to reauth with another endpoint |
17:50.28 | JeffM | bit more complex |
17:50.39 | blast007 | also, we currently don't utilize the checktoken/gettoken methods on the list |
17:50.41 | JeffM | but aything else would rely on crypto |
17:51.02 | blast007 | the client just calls a full 'list' operation when it needs a token, regardless of if it needs to show the server list |
17:51.12 | blast007 | and the server always just called the 'add' operation again |
17:51.17 | blast007 | calls* |
17:52.05 | JeffM | well the server always needs to add when it checks a player right now |
17:52.14 | JeffM | but yes if it was split we could just do the auth stuff |
17:52.32 | JeffM | webservers that use weblogin use checktoken |
17:52.43 | JeffM | and weblogin uses gettoken IIRC |
17:52.58 | blast007 | yeah, but that's a tiny percentage of hits |
17:53.00 | JeffM | yeah |
17:55.12 | blast007 | heck, if we split auth from the forums, we're not even necessarily restricted to MySQL anymore. Postgresql has some interesting features. (Such as a column type for storing IP addresses, both v4 and v6) |
17:56.06 | blast007 | I should check if my host offers IPv6 support yet. |
17:56.42 | JeffM | what would have to happen for bzfs to support IPV6? |
17:57.54 | blast007 | no idea |
17:58.12 | JeffM | well besides "use a lib that supports it" |
17:58.26 | JeffM | that's probalby the best reason to move to something like enet |
17:58.28 | blast007 | ban commands, ban matching |
17:58.33 | JeffM | yeah |
17:58.45 | blast007 | the ipinfo packet |
17:58.53 | JeffM | list server also checks IPs IIRC |
17:58.59 | blast007 | yep |
17:59.08 | blast007 | we store them as strings currently, I think |
17:59.13 | JeffM | ok good |
17:59.37 | blast007 | however, there's some complication |
18:00.00 | blast007 | if they connect to a game server that only has IPv4, that server will only know their IPv4 address |
18:00.14 | JeffM | so the list would have to store both |
18:00.22 | blast007 | but the list would not know both |
18:00.25 | JeffM | hmmm |
18:00.41 | blast007 | it would only know the one they hit it with, which would be IPv6 if they've got that working |
18:00.59 | JeffM | maybe have them make a second auth hit on an ipV6 list server with the token they got form the v4 and we store the v6 IP |
18:01.22 | blast007 | yeah, we'll need some magic glue somewhere |
18:01.43 | JeffM | or stop verifiying IPs |
18:03.11 | blast007 | "Purchase your RSA SecurID here!" |
18:05.59 | blast007 | we could limit the token to the server they are joining to, and reduce the token lifetime to, say, 30 or 60 seconds - and then have the client request the token only when they hit 'connect' in the client |
18:06.37 | blast007 | if it takes longer than 30 to 60 seconds to get the token, connect to the server and send the token.. well.. auth failure, try again ;) |
18:06.58 | blast007 | I wonder how other systems handle this.. |
18:07.47 | blast007 | if the project ran all the servers, it wouldn't be an issue :) |
18:08.53 | JeffM | yeah that'd be better IMHO, keeping the token during the browse period seemed odd to me |
18:09.06 | JeffM | we already have to reget the token if it's old from the list |
18:09.53 | blast007 | hmm.. maybe there could be some handshake done by the list server itself |
18:10.41 | blast007 | have the list talk to the server you'll be connecting to and mediate the connection.. |
18:11.41 | blast007 | but I think I'm overcomplicating things |
18:14.06 | BulletCatcher | For the most part, you are reinventing Kerberos. |
18:14.07 | BulletCatcher | It would be easier to just use the real thing. |
18:14.28 | blast007 | perhaps |
18:25.40 | blast007 | BulletCatcher: with Kerberos, is there anything preventing a rogue server from taking your TGT and authenticating as you elsewhere? |
18:27.38 | JeffM | the token system is fine, we just need to tweak how it works |
18:28.19 | JeffM | if the token channel is SSLed and done during connect then we can lower the token timeout |
18:28.46 | BulletCatcher | With Kerberos you don't send your TGT to the server. |
18:29.11 | BulletCatcher | What you do send is a separate ticket that only that server can use. |
18:30.59 | JeffM | if it's SSLed I'm not sure we need to compare the IP |
18:31.26 | JeffM | and I can see cases whit proxies where the list hit is on a different IP then the game hit |
18:31.29 | BulletCatcher | More precisely, you get a server-specific ticket that only the correct server can correctly validate. |
18:31.32 | JeffM | specialy if we go UDP only |
18:41.12 | blast007 | BulletCatcher: ah, yeah, I was missing the service ticket part of the equation |
20:01.35 | *** join/#bzflag spldart (~spldart2@c-98-199-190-28.hsd1.tx.comcast.net) |
20:01.36 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
20:01.36 | *** mode/#bzflag [+v spldart] by ChanServ |
20:05.31 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
20:05.31 | *** mode/#bzflag [+o TimRiker] by ChanServ |
20:11.53 | Constitution | so? GSoC 2013 is on :) |
20:12.46 | allejo | ^ :o |
20:13.56 | JeffM | Constitution, you going to enter? |
20:17.59 | JeffM | should totaly enter as a student |
20:24.39 | Constitution | let's swap the mentors into students this year and totally get some work done |
20:24.45 | JeffM | heh |
20:25.04 | JeffM | didn't I see that there were only like 11 orgs last year? |
20:25.20 | JeffM | and we can/should totaly get some work done without the students |
20:25.26 | Constitution | I'm thinking about it? can't' remember the last time I had so much fun making so much money |
20:25.37 | JeffM | you need a better job |
20:25.53 | JeffM | still got one open here if you are interested ;) |
20:39.41 | allejo | move to CA, const. you'll love the bipolar weather |
20:39.58 | JeffM | he's been here |
20:40.09 | JeffM | done had pizza several times with Constitution |
20:41.15 | allejo | if I code for bz, will you have pizza with me pizza? :P |
20:41.32 | JeffM | I'd have pizza with you even if you didn't |
20:41.35 | JeffM | cus dude pizza |
20:41.44 | JeffM | pizza also means beers |
20:42.31 | allejo | <- still a minor |
20:42.32 | blast007 | I never have beer with my pizza. Of course, the same is true if I remove the "with my pizza". ;) |
20:42.39 | allejo | well not minor. just not drinking age :P |
20:42.49 | allejo | and besides, not a fan of drinking |
20:43.01 | blast007 | high fives allejo |
20:43.08 | Constitution | allejo: I think AZ has you beat as far as bipolar weather |
20:43.08 | JeffM | a valid choice |
20:43.20 | JeffM | I'd still buy you a pizza |
20:43.38 | JeffM | yeah AZ can be wacky |
20:43.41 | allejo | high fives blast |
20:43.58 | JeffM | pheonix in the summer, no thank you |
20:43.58 | Constitution | but yes pizza with JeffM is awesome |
20:44.11 | allejo | Constitution, hehe i know the summers get really hot, are the winters really cold? |
20:44.19 | JeffM | blast007, how about a root beer? |
20:44.26 | blast007 | JeffM: that works :) |
20:44.30 | JeffM | cus the place we had pizza makes there own and it's SUPER good |
20:44.32 | allejo | and awesome. i'm having pizza with jeff one day |
20:45.19 | JeffM | my dad lives in a place in AZ that gets hotter then here in the summer, and snows in the winter |
20:45.23 | Constitution | allejo: not usually (at least in my part of the state), but the weather is unpredictable and changes suddenly |
20:45.29 | JeffM | here it just gets a little cold |
20:45.33 | blast007 | closest I've been to California is when I was at Vegas |
20:45.55 | JeffM | I thought you went to the SOC mentor fest? |
20:45.58 | blast007 | nope |
20:46.08 | ashvala | I heard Pizza |
20:46.11 | JeffM | you should have, those are fun |
20:46.16 | blast007 | ashvala: hehe |
20:46.40 | JeffM | BulletCatcher made tank cookies |
20:46.50 | JeffM | well his wife did |
20:46.56 | allejo | Mrs. Catcher :D |
20:47.01 | JeffM | have to credit her because of the GPL |
20:47.07 | allejo | hehe |
20:47.32 | allejo | Constitution, hmm alright then, I'm staying away from AZ |
20:48.21 | allejo | and blast007, i think you mean the closest you got to LA was a hotel in vegas, I thought you didn't leave your hotel :P |
20:48.32 | Constitution | the GPL lol |
20:48.52 | blast007 | I left it every day |
20:49.03 | blast007 | when I had to ;) |
20:49.13 | blast007 | I wasn't training the people from my hotel room |
20:50.19 | JeffM | vegas can be 'bleh' in the summer |
21:09.42 | Constitution | JeffM: looks like there were 180 organizations participating in GSoC 2012 |
21:09.51 | JeffM | ahh good |
21:10.12 | JeffM | I saw a link to "winners" and thought it mentioned 11 orgs |
21:10.32 | JeffM | with 180 orgs I'm sure I can find one to try |
21:11.22 | blast007 | I think the Google Code In had 11 or 12 |
21:11.32 | JeffM | ahh that must be what I had seen |
21:12.13 | blast007 | http://www.google-melange.com/gci/accepted_orgs/google/gci2012 |
21:12.19 | blast007 | I see 10 orgs there |
21:31.11 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
21:31.11 | *** mode/#bzflag [+o TimRiker] by ChanServ |
21:45.06 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
21:45.06 | *** mode/#bzflag [+o TimRiker] by ChanServ |
22:05.34 | *** join/#bzflag Fira (artix@unaffiliated/fira) |
22:22.05 | JeffM | so should change the screenshots I mocked up to be more like the mainsite blast007 ? |
22:22.40 | blast007 | let me think a bit more about what depends on what |
22:22.45 | JeffM | k |
22:23.10 | JeffM | it would be nice to have more consistent themes on all the sites |
22:23.53 | JeffM | and I do still wonder how hard it would be to get bzflag keychains made |
22:40.48 | Constitution | mockups?! |
22:44.49 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
23:21.13 | JeffM | Constitution, yeah on the wiki for the master-child account system |
23:23.25 | JeffM | http://wiki.bzflag.org/Master-ChildAccountSystem |