Staredit Network

?p=usercp&vars[]=1
I don't know if that'll mess anything up security wise.

Anyways, I optimized the global wrapper, took of 3kb without counting deleting the affilerates / bottom image done (until I get it done which is when... you can ask me if you want to know). 3kb off is pretty damn good for the global wrapper...

On another note, I still highly, highly think all html entities should be automatically cleaned out of post data. I can't imagine a situation where characters like < > & would be valid input without &lt &gt &amp also being valid input.
If a post/get name or get value contains anything besides a-z, A-Z, 0-9, the script should just break right there. I can't image a situation where WE would need any special characters inside an array name or get value.

God damn it... I want to use:
foreach ($arr as &value)
and I can't because it's php 5 ;/

---

Worked around it with array_walk + recursive function. So... it's a recursive callback function I guess . "I don't see anything in PHP5 worth switching for..." yeah... lol, it would have only saved a shit load of coding and frustration right there.

No ' " & < > % means no possibility of sql attacks? I mean, what could you possible do? If GET isn't alphanumeric, the script dies on you... so you couldn't possibly try to break sql statements inside the url. You can't change post keys to non_alphanumberic, and no ' " & < > % \ in post values means zero possibility of embedding something inside any type of input.

I think it's the ultimate security... except I'm not too sure on "/". Is there anything you could do with a slash? It's not 100% security, you could vary well code some noobish post function, passing a direct variable into an sql command where they could enclose it with ` and then execute a second query... but mmm.

All that's needed now is security inside bbcode parsing because that's the only thing that should be converting TO < >'s.

For gets, you only need letters and numbers (I even added the _)

I said. Its the perfect security prevention. Theres nothing you can do to it. Actually, it might not support negative numbers either, I'd better add support for that.

Whitelisting > Blacklisting.

If you understood your own code, you would understand why you wouldn't need to worry about negative numbers.

I allowed _ to pass just because you did. If you won't need it, I'll remove it, cuz I won't need it.

Anyways, yeah, whitelisting is better than blacklisting, however, it wouldn't be too efficient to break all post strings into arrays. I used your style of converting the string to lower characters, but that's just asking for frustration later on (you wouldn't be able to use ?Something=hello) or anything remotely uppercase in the urls.

I really don't believe in just making invalid characters disappear from variables. Just crash the script and be done with it. Any invalid input needs to die anyways. Hmm... looking at the url up above, we both forgot to allow #'s.

Look at the code in index. User input needs something automatic. It'll be nerve wrecking to constantly do the same calls forcibly on all posted values.

purity() and sniper() are good names for the functions I used . Although, they would be more meaniful if I switched the names I suppose. I have to redo the character checking in purity, I didn't use the right sets.

What do you mean 'if I understood my own code'? Are you trying to tell me I didn't write it or something?

Yeah, I don't. We can remove it.

Converting to lowercase is better. It means less errors in URLs if you accidentally put an uppercase letter. Why would you have foRums and forums as two different pages anyway?

No, but it's easy to see why negative numbers wouldn't make a difference even though it's not my code. You return only valid characters and invalid onces simply disappeared. So &var=he/lo-s would be like post['var'] = helos.

kk.

True that, you're right.



There's like over 100 ways to display <. All must die. Between purity()'s script death and sql obsecurity (although, sql statements should NOT be killable with sniper()) and no direct post variables into sql statements, I think that's 100% security outside the bbcode parser.

I know. But what if you intentionally WANTED negative numbers? It would simply be turned to positive.




Maybe later, I'll try to do a BB code parser and see how it goes...

Ah, I misread like your first post. I thought you said something along the lines of protecting against negative numbers instead of adding support for it... um... oops? . If such a situation would occur, either of our code could easily support it.

Don't worry about the bbcode parser...
I'll hopefully work on it a bit more in the next few days. I'd rather have you finish up the forums, optimize it, and get it to a testing stage. And then finish the login script, dividing the validation functions into easy to call functions for my usercp to call for account management, as well as, of course, killing all the old code so I can delete it from the other core scripts.

Generally, I liked how you took the inititive to keep post and get variables seperate...
However, look how it makes things a bit messy for search filters:


Anyways, call $vars->merge() to fix situations like this, it'll place all get and post variables inside $vars->input.

With the whole post and get thingies, it's generally pointless to place them in $vars->, as they could just be accessed directly with $_GET... and it we wouldn't have to call global $vars in order to access the information. I think that's what I'm going to do, I'll keep the line "$this->post =& $_POST;" in play though .
Is there anyway to exalt variables to a superglobal position? Hmmm...

---

Changes:
Added gborder class to css... green border...
Played around in sessions.php... cleaned things up a little and such.
Tweaked parse_pages a bit.

For me, im almost done dollwar...

Some CSS changes...
input[type="submit"] {border: 1px solid lightgreen;background-color: #000; vertical-align:top;padding:3px;}
input[type="checkbox"] {padding:0px; margin:0px;}

only works for firefox and other css compliant browsers. Basically, it sucks in IE. Basically, the entire page sucks in IE. I hate IE.

Anyways, another global type change that you probably haven't even begun to use yet:
Any form wishing to take advantage of global javascript or such functions like attachment, smilie, or bbcode interfaces must be called "cform"...

I'll continue to edit this post with any changes worth notifying you.

---

One thing that will be annoying to members is the fact that clan tags will appear as member names, so, if they did a search or composed a pm using the clan tags, the user wouldn't technically be there.

Oh wow... many days past since I worked on senv5 . Stupid life.

Anyways, here's some additions to the global scope:
Any GET variables as "id" or "mid" with an assignment of a non-positive real numer kills the script. Having no value also crashes the script.
Any POST variable as "mname" checks the assignment for valid user name characters.
This allows you to directly insert these post or get values into sql queries safely (as no characters that could make an sql injection attack possible are valid).

configuration.php is laid to rest. There are still some script shared variables in the variable wrapper class's constructor function, so $vars->config still exists, but it exists solely to share common variables needed by scripts for easy changing. For example, you threw $vars->config['rules'] in there for sole use for the login script, it's unnecessary as a private script.

vars->purity has been changed to allow it to be used as a global function, rather than just a post/get check function. So far it's rather useful, however, it might be rewritten, so use at your own risk.

So with that, back to working on the messenger class. Hoping to get it finished today, maybe .

So whats the progress report? ETA?

I have no clue on the ETA, all I know is that it probably won't be this month(May).

I'd suggest sometime during Summer so that we could emphasize some more on fixing bugs and other site related issues during it's initial launch and/or if there ever is a private alpha/beta of some sort for testing.

You can be sure of a limited alpha testing during that time, if not sooner.

Uhhh... yoshah... what's up with the msg_code/skin.php?
And what's ranking and the crap load of other new files?

Wait... I know what they are now . I was thinking you wanted to take over the message center.

Any progress on v5? Just curious.


On semi-related notes:

So far, we've used 27 gigs of bandwidth and we are almost at the half way point of the month, so that final dldb function I killed seemed to be the biggest problem. Well, the hits have been suffering lately as well, but none the less...

Cron seemed to have died again.

Uh... forgot what else.

Not really. I have a calculus test tommorow, then an assignment after that.... so yeah. Things are pretty messed up at the moment.

Sorry, I uploaded wrong files