I'm trying to implement the best practices recommendations for the Well-known Change Password URL spec. I've gotten the redirect to the login form from ./well-known/change-password implemented, but I have no idea how to go about adding the autocomplete="current-password" and autocomplete="new-password" attributes to the login form's input fields.
This is a rather crude method. It can stop working in new versions of MediaWiki. Insert into your LocalSetings.php or make a new MediaWiki extension with:
// This hook is run every time that a special page is ready to be output.
$wgHooks['SpecialPageAfterExecute'][] = function ( SpecialPage $special, ?string $subPage ): bool {
// Only Special:ChangeCredentials should be changed.
if ( $special->getName() !== 'ChangeCredentials' ) {
return true;
}
$out = $special->getOutput();
// The HTML for the page is already formed.
// Inject autocomplete='new-password' into input boxes for both the new password and its confirmation.
$out->mBodytext = preg_replace(
"/(<input )(.*?name='(password|retype)'.*?>)/",
'$1autocomplete=\'new-password\' $2',
$out->mBodytext
);
return true;
};
If you want to do it for your own wiki, then (assuming a recent MediaWiki version) the AuthChangeFormFields hook is the right place to do that.
If you want to do it for MediaWiki in general (patches very welcome! feel free to add me as a reviewer) then LoginSignupSpecialPage::getFieldDefinitions() has the field definitions for account creation and login. I believe that also includes the forced password change form you get during login when your password is too weak.
The stand-alone password change form is generated by the SpecialChangeCredentials class, but there is no form alteration logic there (in general login forms in MediaWiki 1.27+ are rather abstract, as there is no guarantee the site uses passwords at all), you'd have to add that yourself. It would work the same way as for the login form - implement SpecialChangeCredentials::onAuthChangeFormFields(), and add whatever HTML properties are needed to the form descriptor array.
Related
I'm trying to setup a MediaWiki for university students. Using the EmailDomainCheck, I prevent anyone except those with a university based email from creating accounts. Using $wgEmailConfirmToEdit, I can require that an email is confirmed before the user can edit files. However, as it is, a user can use a fake email from the correct domain to create an account. With the account they can view all pages (even though they cannot edit them). I do not want to grant them read access unless the email has been confirmed. Is this possible? Note, I want all confirmed emails of the correct domain to be automatically accepted. It should not require manual account creation acceptance.
You could try the following, as outlined in the Documentation
# Disable for everyone.
$wgGroupPermissions['*']['read'] = false;
# Disable for users, too: by default 'user' is allowed to read, even if '*' is not.
$wgGroupPermissions['user']['read'] = false;
# Make it so users with confirmed email addresses are in the group.
$wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
# Hide group from user list.
$wgImplicitGroups[] = 'emailconfirmed';
# Finally, set it to true for the desired group.
$wgGroupPermissions['emailconfirmed']['read'] = true;
As Jenny Shoars has mentioned, you may wish to whitelist some pages such as:
$wgWhitelistRead = array("Main_Page", "Special:CreateAccount", "Special:ConfirmEmail");
So that non registered users can still create accounts and the like.
In theory,
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['emailconfirmed']['read'] = true;
should work. In practice, MediaWiki almost always used with an "everyone can read" or "you can read iff you are logged in" setup and others are not very well tested, so if that wiki had some highly sensitive private information I wouldn't do this, but I imagine for a university website that's not the case.
Alternatively, it should not be too hard to integrate an email confirmation step into account creation, but you'd have to write the code for that. EmailAuth (which does a similar check during login) might give you an idea of how that would look.
in my html form there are two fields for password, one password and other confirm password. If the first password field does not match the second password field than do not submit the form to the database.
This is kind of a long shot since I don't know what your code looks like but this is a javascript example of disabling the submit button until passwords match.
var pass1 = document.getElementById('p1');
var pass2 = document.getElementById('p2');
if(pass1.value == pass2.value)
{
document.getElementById("enableButton").disabled = false;
}
else {
document.getElementById("enableButton").disabled = true;
}
Without knowing anything about your code - you should (could) do two things:
Verify that both passwords are the same via JavaScript on client side. That will bring up a better user-experience as you are able to display an error message / disable the form submission when the passwords are not the same. But please consider - many users still have disabled javascript by default, so that can not be the only validation.
Verify that the passwords are the same in PHP / Server-side code. How exactly you would achieve that depends on your scripting languages / architecture.
There are some in-depth discussions out there regarding password / authentication best-practices: this discussion or this cheat-sheet at owasp or this one in the php faq. Please take the security fundamentals mentioned there into account, too.
I wonder what are the techniques i can use to avoid users to post form twice when they refresh page and chose submit again?
e.g. i have form inside regiter.php and process it as well inside register.php.
1st i could process in another file e.g. register_process.php and redirect to register.php, but then i have to create about 20 new pages and relocate a lot of code, i dont want that option.
2nd i could play with headers i dont remember exact trick but had some bad experience with that - users seen old data on page after refreshing it...
3rd i could just redirect upon success to some dummy.php and from dummy.php jump back to register.php then even if they refresh page browser would not re-post, however it does not protect against them using back button and choosing re-post, i know i could expire page, but i find that annoying experience for me and probably other users to see page expired error.
4th use some unique "access key" for each form once page loaded that will post with form and once used cannot be reused, however i kind of struggle with logics of that feature. how do know key was used without storing it in MySQL DB, i think time based accesis not great either because some users can take long between page open and form submit.
I need more suggestions how to avoid users reposing form again.
Try this:
<?php
session_start();
if( strcasecmp($_SERVER['REQUEST_METHOD'],"POST") === 0) {
$_SESSION['postdata'] = $_POST;
header("Location: ".$_SERVER['PHP_SELF']."?".$_SERVER['QUERY_STRING']);
exit;
}
if( isset($_SESSION['postdata'])) {
$_POST = $_SESSION['postdata'];
unset($_SESSION['postdata']);
}
This will basically save the POST data and cause the browser to re-request as a GET request.
5th. Use AJAX or jQuery and when the form is clicked on the page submit that data in the background. Output a response to the screen. Mark that form as submitted, or save to a session, and when they refresh they will not be able to submit the form again.
In my opinion it is the best way to do it anyway. I had a scoreboard with 20 or more forms it is worked really well to send the data without refreshing. You can return a response and make the page look very professional. Using jQuery you can also use some great form validation to make sure that they are submitting the fields that are required.
I think that the best solution would be something like this:
* create a md5 or base64 of posted data
* compare this hash with a session variable (let's call it $_SESSION['repost'])
* if hashes match, skip whatever this save should do and output a warning
* if hashes do not match, or hash is not present
* assign session variable with current hash
* do whatever save should do
When you consider the first option, I don't know about the design (programming design ^^) of your website, but you should only need 1 page. Let's says you call redirect.php with all the parameters, you should call your controller and your controller should know regardless of the parameters what to do with them.
It is a good habit to be able to do some abstraction and good design when programming, it help alot in those situation.
Other way is store the last post in the session variable, and check if is equal, like this:
<?php
... program ...
if ($_SESSION['PREPOST'] == $_POST) {
// DO SOMETHING
}
... program ...
$_SESSION['PREPOST'] = $_POST;
?>
I'm developing a flash registration form and I need to incorporate dynamic 'captcha' images for confirmation.
Can anyone recommend a best solution for doing this?
Captcha is used to prevent bots from submitting html forms which is easily accomplished since html is easily understood and processed programmatically. The same is not true for a Flash application. It would be difficult for a bot to generically submit Flash forms if it was not specifically made to target your site.
Therefore you don't need to worry about the spam problem captcha solves when working with a Flash application.
Making a strong captcha is not a trivial task. It must be hard enough for bots to fail, but easy enough for humans to succeed... I would take a look at existing systems and possibly use them. reCAPTCHA is popular http://recaptcha.net/ . It might be possible to use it through flash, but I have not looked into it.
It's not that different from a captcha in an HTML form, really.
Suppose you're using php on the server and you have a captcha.php scritp that generates the captcha image and saves its value in the session. In an HTML form, you'd use an element and set its src to captcha.php. The user would fill up a field with the text they see in the image. In the script that receives the post, you'd check if the user input matches the session value.
In a flash form, it's exactly the same. You load the image calling captcha.php and ask the user to type the extra field. Then, when you post the data to the server you pass the value typed by the user in the captcha field and the server matches that against the value it has stored in the session when you called captcha.php.
So, basically, it's the same as in an HTML form.
Chances are, bots aren't going to be written for your website. If the need ever arises, a simple "add these two numbers for me, k?" would be simple enough.
In all honesty, i doubt someone would write letter recognition to sign up a few hundred times on your website =/
You should be more worried about someone disassembling [or whatever the flash term is] your .swf s and simply sending "register" messages to your server =/
And yes, by that, i tried to imply that Captcha must be applied server side, or, really, its not that hard to go around.
We had a strong need to implement CAPTCHA into a flash animation/form.
The most important point to note is that either FF or IE (can’t remember which one) doesn’t send any cookies back with a web service call. So if you’re submitting your form to a .Net web service you can’t use the session state of the http request to store the captcha text and then compare the user entered captcha value on submttion to the web service (session enabled web method)
We implemented the following:
Set a unique token value (Guid) on the web page
pass this token as a flashvar to the flash movie
load the captcha image into the flash with the token as a url param. Ie captchaImg.aspx?t=xxxxxxx
during that request save the random captcha text in a table with the token
when the user submits their form, compare the token and user entered captcha value with the one in the table
This approach works very well for us.
It’s also web farm safe.
public class Captcha extends Sprite{
private var question:String = "How do you feel?";
private var _answer:String;
private var isRobot:Boolean;
public function Captcha(answer:String){
_answer = answer;
}
public function checkAnswer():Boolean
if(answer != "sad"){
isRobot = true;
return isRobot;
}else{
isRobot = false;
return isRobot;
}
}
}
Say a user is browsing a website, and then performs some action which changes the database (let's say they add a comment). When the request to actually add the comment comes in, however, we find we need to force them to login before they can continue.
Assume the login page asks for a username and password, and redirects the user back to the URL they were going to when the login was required. That redirect works find for a URL with only GET parameters, but if the request originally contained some HTTP POST data, that is now lost.
Can anyone recommend a way to handle this scenario when HTTP POST data is involved?
Obviously, if necessary, the login page could dynamically generate a form with all the POST parameters to pass them along (though that seems messy), but even then, I don't know of any way for the login page to redirect the user on to their intended page while keeping the POST data in the request.
Edit : One extra constraint I should have made clear - Imagine we don't know if a login will be required until the user submits their comment. For example, their cookie might have expired between when they loaded the form and actually submitted the comment.
This is one good place where Ajax techniques might be helpful. When the user clicks the submit button, show the login dialog on client side and validate with the server before you actually submit the page.
Another way I can think of is showing or hiding the login controls in a DIV tag dynamically in the main page itself.
You might want to investigate why Django removed this feature before implementing it yourself. It doesn't seem like a Django specific problem, but rather yet another cross site forgery attack.
2 choices:
Write out the messy form from the login page, and JavaScript form.submit() it to the page.
Have the login page itself POST to the requesting page (with the previous values), and have that page's controller perform the login verification. Roll this into whatever logic you already have for detecting the not logged in user (frameworks vary on how they do this). In pseudo-MVC:
CommentController {
void AddComment() {
if (!Request.User.IsAuthenticated && !AuthenticateUser()) {
return;
}
// add comment to database
}
bool AuthenticateUser() {
if (Request.Form["username"] == "") {
// show login page
foreach (Key key in Request.Form) {
// copy form values
ViewData.Form.Add("hidden", key, Request.Form[key]);
}
ViewData.Form.Action = Request.Url;
ShowLoginView();
return false;
} else {
// validate login
return TryLogin(Request.Form["username"], Request.Form["password"]);
}
}
}
Just store all the necessary data from the POST in the session until after the login process is completed. Or have some sort of temp table in the db to store in and then retrieve it. Obviously this is pseudo-code but:
if ( !loggedIn ) {
StorePostInSession();
ShowLoginForm();
}
if ( postIsStored ) {
RetrievePostFromSession();
}
Or something along those lines.
Collect the data on the page they submitted it, and store it in your backend (database?) while they go off through the login sequence, hide a transaction id or similar on the page with the login form. When they're done, return them to the page they asked for by looking it up using the transaction id on the backend, and dump all the data they posted into the form for previewing again, or just run whatever code that page would run.
Note that many systems, eg blogs, get around this by having login fields in the same form as the one for posting comments, if the user needs to be logged in to comment and isn't yet.
I know it says language-agnostic, but why not take advantage of the conventions provided by the server-side language you are using? If it were Java, the data could persist by setting a Request attribute. You would use a controller to process the form, detect the login, and then forward through. If the attributes are set, then just prepopulate the form with that data?
Edit: You could also use a Session as pointed out, but I'm pretty sure if you use a forward in Java back to the login page, that the Request attribute will persist.