Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Arantor
2716
Features / Re: $db_passwd and $ssi_db_passwd stored in a .htpasswd-like file
« on October 3rd, 2012, 12:38 AM »
Interesting concept, actually. I'm not entirely sure it would be bridged into Aeva (or, Wedge, as it's now called :P) but it's an interesting concept nonetheless. Personally I don't think I'd use either Java or ActiveX were I to go about doing it, I'd probably be trying to use canvas tags (OK it doesn't work on IE below IE9 but that's no big loss to me personally)
2717
Features / Re: $db_passwd and $ssi_db_passwd stored in a .htpasswd-like file
« on October 3rd, 2012, 12:24 AM »
Quote
I apologize if I'm not up to snuff when it comes to advanced web development.
I'm sorry that I'm being somewhat unfriendly. There's a lot going on. (That, and the fact I get annoyed when I feel like I have to explain something multiple times because I'm not being heard. It's one thing not to understand, it's another to ignore it. If something I'm saying doesn't make sense, ask, don't assume.)
Quote
I was thinking of hashed passwords to put outside the web root.
As explained above, this is not particularly practical (since you have to have an unsecured password somewhere along the line in the actual PHP anyway, everything else is pure misdirection), but on top of that if you put it outside the web root, you actually raise a whole bunch of other problems, namely the insanity that is open_basedir.

In other words, just consider for a moment what I've said above. If you put the configuration outside of the web root, how does Wedge know where to get it? You then have to have configuration somewhere where it knows where to find it... which means you have a configuration file to find a configuration file, which is more than a bit redundant and not to mention making you think you're secure when really you're not any more secure than you were before doing it.
2718
Features / Re: $db_passwd and $ssi_db_passwd stored in a .htpasswd-like file
« on October 3rd, 2012, 12:13 AM »
Um... what would you put in it, exactly?

Wedge already has an .htaccess file that is used to handle routing for pretty URLs...
2719
Features / Re: $db_passwd and $ssi_db_passwd stored in a .htpasswd-like file
« on October 3rd, 2012, 12:10 AM »
Quote
Oh, I see. Well I was a bit worried that the password is displayed in plain text.. what if apache/nginx is misconfigured and instead of serving the file (Settings.php), it's downloaded..?
It actually doesn't matter. At some point the file has to be accessible to PHP to send to MySQL. If it's misconfigured, it's misconfigured and you're stuffed anyway.

Though if it is served, for whatever reason, that password is no more vulnerable than it would be before, IMO.
Quote
Also, letting admins move that file around the server (for example in /var/www/something/.. or /home/user/...).. it's more likely to be protected there (it's more difficult to mess with permissions)!
So you're going to make a settings file to record where you're putting the settings file? I'll let you do that while making a settings file to record the location of that settings file.
Quote
It would be useful for adding on more php features to a community without having to make a bridge.
Um, no? It's... nothing whatever to do with this? This is about securing the set up you have and protecting the password that is used from the PHP to talk to the database, not a password the user uses to access the site.

In all honesty it would be better to integrate features rather than relying on the absolutely more primitive method of securing.

To explain: HTTP Basic not only sends the password in plain text, it sends it EVERY SINGLE PAGE REQUEST. Even image requests include the password. You might as well not bother sending the password at all since quite literally any network sniffer anywhere between you and the server can access it.
2720
Features / Re: New revs - Public comments
« on October 2nd, 2012, 11:38 PM »
Quote
So, what you're saying is that updateSettings can be called without issues in the installer as long as wesql is loaded..? (I haven't looked into it...)
Not entirely. The error it fails on, at the first hurdle is the wesql is not loaded. But that's symptomatic of a larger problem - it isn't going to get database settings it can actually use until the beginning of the third step (step 1 = welcome + checking for fundamentals, step 2 = gathering database settings, step 3 is getting other stuff)

That's really why I took the step I did - blocking all updateSettings calls until the very last step of the installer (which itself calls updateSettings, albeit indirectly)
Quote
And the HTML had what...?
Not a fat lot in it, seeing how it was fatally erroring out during population of the <head>. Consider the backtrace that would be occurring: a language file is loaded at the start of installation, but it fails there - the only thing that exists is the <head> tag, it's failing after the head tag is output.
2721
Off-topic / Re: Happy birthday, Arantor!
« on October 2nd, 2012, 11:17 PM »
Thank you everyone :)
2722
Features / Re: $db_passwd and $ssi_db_passwd stored in a .htpasswd-like file
« on October 2nd, 2012, 11:16 PM »
Quote
What about storing those variables in a MD5 encrypted file?
Not possible at all.

Problem 1: you can't retrieve them from an md5 encrypted file. But you have to store them in a fashion that PHP can send to MySQL, which means either not encrypting them (like we do now), encrypting them in a fashion you can retrieve later (which brings me on to problem 2), or storing it in the same fashion that MySQL uses and connecting with that directly (which brings me to problem 3)

Problem 2: If you encrypt them somehow, you still have to be able to decrypt them to be able to use them.

Problem 3: If you store them the way MySQL does, it's realistically no different to storing the password as-is, either way someone who gets access to that password can still get into your database and mess it up.

What were you hoping to protect with this setup?
2723
Features / Re: New revs - Public comments
« on October 2nd, 2012, 11:13 PM »
Quote
Not completely, though... updateSettings is called before even WEDGE_INSTALLER is defined, because the language files are loaded first. I worked around that by initializing language strings only after setting the constant, with an $init var to ensure it's only done once (because we're inside a loop at this point.)
Odd, if that were true it should have failed before that - the error in question is that wesql doesn't exist, which is why updateSettings fails. wesql can't exist until there are DB settings and if it does work it means it's using settings it shouldn't be.
Quote
The problem doesn't show up at first because the error message(s) (with XDebug) are shown inside an HTML tag, so you can't see them on the HTML rendition.
No, I just got to a screen that only had a gradient and nothing else... ;) I couldn't even press anything to go to the next page.
Quote
I don't remember asking you about head, though... Or maybe that was a long time ago?!
It was last week - http://wedge.org/pub/feats/6803/new-revs-public-comments/msg282124/#msg282124
2724
Features / Re: New revs - Public comments
« on October 2nd, 2012, 03:01 AM »
That would be the case if it weren't for the fact I'm talking about two completely different problems.

The problem of the installer crashing and burning is still related to updateSettings. The installer hack gets around that.

The problem of sbox.js being undefined on every single fresh install has been a problem for many months now. I was attempting to debug it - at which point you asked me what was in <head>, I attempted to do a fresh install to see what the state of play was, only to find it completely broken... but this problem is not resolved.
2725
Features / Re: New revs - Public comments
« on September 30th, 2012, 11:10 PM »
It has been doing it for months on every single fresh install I perform.

The fix I've added is just enough to get through installation, it doesn't change this problem.
2726
Features / Re: New revs - Public comments
« on September 30th, 2012, 05:29 PM »
Quote
I don't have any problems with sbox.js myself. Are you sure you can reproduce this...?
Every fresh install reproduces this, without fail, even on a real server. Try it - grab all the files except for other/ and put them into a folder, then also grab the Settings and install files from other/ and put them in that folder, and run it.
2727
The Pub / Re: When can I download Wedge? / Where can I download Wedge?
« on September 30th, 2012, 05:02 PM »
Consider what would happen if we did accept money for the project.

For every person that provided money, there would be an increased implication of owing something. If you give money, you expect something in return, it stops being anything other than a contract of sorts.

There are already enough people who are demanding and expecting things, accepting money would make that worse, and in all honesty I don't see how it would accelerate anything.
2728
Off-topic / Re: Doctor Who
« on September 30th, 2012, 03:00 PM »
(click to show/hide)
Quote
Well, that particular reason was cheesy as hell.
What choice does he have? The way it's set up, it's not 'finding a reason not to go look' but 'finding a reason so he can't'. When you have a time machine, almost anything becomes possible.

They're told that Rory is going to go back and he knows out that if he kills himself, it'll create a paradox. So he kills himself and explosively deals with the situation. But when they thought they've dealt with it, an Angel has escaped... the TARDIS really does not like being near paradoxes (c.f. season 3 ending) and somewhat unsurprisingly can't go back there. It might seem lame, but short of repeating last season by making the event a fixed point in time, there's not really a lot you can do with it.
Quote
Also... Statue of Liberty, EH? Come on... I know it's a kids show, but still...?
I thought that was a neat touch, especially given the fact that in NY, *someone*'s going to be looking at the Statue of Liberty anyway so there's never really a risk of that.
Quote
(And that's probably why we learned earlier on that she started writing articles for a magazine, eh..?)
Remember Blink. The policeman that got thrown back in time went on to get into publishing specifically so that he could put the easter egg into the DVDs.
Quote
I know many don't like her, but I hope she sticks along, like she promised... :)
I'm not entirely sure what there is left for her to say. The arc of her timeline is now complete - the next point in her timeline, really, is in the Library. She's now a Professor, she's now an archaeologist. There are no gaps that need to be filled in continuity between where she is now and the Library. That said, I'd love to see her around for the 50th, and if she has a vortex manipulator, maybe Jack's there too... :whistle:

(click to show/hide)
Judging by the comments that have been made on the subject and what has been leaked about the Christmas episode, they have a different but related name, so it is entirely possible that she is a relative, or there is something we don't know about yet.
2729
Features / Re: New revs - Public comments
« on September 30th, 2012, 04:38 AM »
Seems that sbox.js is minified into things when jquery_origin is local but not when it isn't - at least for me.
2730
Off-topic / Re: Doctor Who
« on September 30th, 2012, 04:32 AM »
No, it's not.

Early in the episode is a huge spoiler of what is going to come.

(click to show/hide)
The kicker is that a few minutes from the end you think they've done it, that they're going to survive, and BOOM. It's a hell of an episode. Even though I knew what was coming, I knew full well and I still thought that somehow they were going to get away with it.