Wedge

If and when we go down the road of financial support, that's where I suspect we'll go first.

Yes, but we don't actually say anywhere that the file applies...

That's the thing. I've worked professionally in the past with various helpdesk systems, with intranet/extranet tools, financial infrastructure systems as part of my former career in financial services - and of all the web based tools I used, even those where multiple firms had login details to the one system (think credit reporting systems), even those did not have email address, but username, logins.

In fact, of all the services I have used and continue to currently use that have the 'professional' mentality attached, more of the services I use do not use my email address as my primary login, though all of them have my email address, so I'd argue that's probably not a great case to make either in the name of using emails for 'professionalism'.

There IS a case that can be made for using email authentication. It's really not a great case, especially if you change email addresses, make a typo and then you're really locked out of your account. (Yes, you can be locked out of your account otherwise for the same reason, but realistically you have a better chance of getting it fixed if you have a username attached to it that you're normally using.)

I should point out that this debate has already been had, once on sm.org, once here before. The fact remains that people will continue to be insecure in spite of any measures you place making them more secure, and if someone can type in a username instead of an email address, they invariably will, because it's easier.

Case study: I used to work at a corporation that had a 30 day expiration policy on passwords. Each password had to be a minimum of 8 characters, use no dictionary words, must include upper and lower case plus at least 2 characters that were either digits or symbols. Oh, and not reusing any of the last 3 passwords.

This was for financially sensitive systems, whereupon you would regularly have people phoning up IT to change their passwords because they couldn't remember them. Unless they wrote them down on post-it notes on their monitor. This sounds like an urban legend but I saw it happen every single day.

The consequence is that the more you do to make it more secure, the harder it is for users to use: complex passwords that change regularly mean users try to find easier passwords to remember, bearing in mind the potentially short term therein.

The moral of the story is that users will use what is easiest, not what is theoretically best. That's why people still use 'password' as their password, because it's easiest for them to remember.

You did, yes, and I thought glancing at your latest commit you'd answered that question.What does that actually mean for users?

Presumably, a user should be able to pick any skin from any currently available theme? (Assuming admins allow them to choose) If that's the case, does it need to remember which skin within a given theme that a user picked?

i.e. if you have two actual themes, and two skins in each (Themes 1 and 2, skins A & B, giving you 1A, 1B, 2A, 2B), when the user picks a skin from 1 (say 1B when 1A is default), then switches to 2 (either), should the fact they picked 1B be remembered if they come back to 1 later?

I'm inclined to think not, which without looking over finer points, seems to me to suggest we don't need it and only need to bother with what the user currently has selected, i.e. in their record in the members table.

I think it's fairer to say that they weren't "broken repeatedly with each RC" - each RC did have more bug fixes for the PGSQL stuff, and almost nothing for SQLite, but no-one really tested them that thoroughly, and as such the bugs that are coming to light are simply ones that fell through the cracks.

Oh, I finally found out what it was. It's the fact that it lags looking up 'localhost' in DNS, since using 127.0.0.1 works just fine.

Meanwhile I appear to have permanently broken phpMyAdmin's ability to connect. This is awesome, especially because I have no fucking idea how it happened.

For reasons too long to get into, all my local stuff is run with a root user with a password. root@localhost, root@127.0.0.1 and root@% are all defined and valid users in the mysql table. SMF and Wedge connect just happily with any of the above settings.

But phpMyAdmin won't. At all.

If I give it root@localhost, no password, it fails - understandably. But if I tell it root@localhost, with the right password, it tells me it can't connect root@127.0.0.1 (using password: YES). Which, considering they have the same password, is interesting. (Yes: it's actively converting the domain name into an IP)

And root@127.0.0.1 doesn't work either, even though it has the same password as the other root accounts (just varying the hostname)

No, it doesn't, especially since not everyone actually wants a serious and professional environment.No, it isn't. If it IS implemented, I certainly won't be doing it.And you think this is a common occurrence? Trust me, it isn't. I run multiple honeypots right now, and while each has been hit with brute force attacks, the vast majority of them are for users that don't even exist.It's better than that, it's not merely "by default". You physically have to give out moderation level permissions for it in order to view them.Hardly. I have a very long list of things that ranks higher than this, sorry to say.

Seriously, please take a note of the comments I have already made, specifically the ones where I indicated that the bots are already trying to brute force email addresses, and that not permitting very common, very weak passwords is actually a better method of protecting users than this.

Consider it this way: in any fence of security, the weakest link is where efforts will be concentrated. Usernames are not that weakest link.

Consider this also: you know Facebook, that little site with 750m+ users? That allows login with username. I know, because I happen to use that every damn day. Consider additionally that it's not just a random username then, it's also an *identity* of sorts, with all sorts of personal information far more important than would be found on most forums.

That's the point, it's a surprise :D Though it was something you said that made me think of it... You'll see soon enough!Yes, yes it is.That applies to every single page in the admin panel. It's done for a while and I think it's a bug of ours (i.e. I can't reproduce it in SMF). I suspect the change to tab_data is responsible from a bit back, but I'll take a look shortly.

Or I will perhaps in a bit longer since my WampServer configuration isn't working properly. Might be conflicting with my original Apache setup >_<