The following warnings occurred:
Warning [2] Undefined variable $unreadreports - Line: 26 - File: global.php(961) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/global.php(961) : eval()'d code 26 errorHandler->error
/global.php 961 eval
/showthread.php 28 require_once





× This forum is read only. As of July 23, 2019, the UserSpice forums have been closed. To receive support, please join our Discord by clicking here. Thank you!

  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Status Update 022
#1
Fixed a few bugs in admin_users caused by removing fields from the users table.
New dump available. I'll be redoing all the auto increments before release for new users.

Added a few new hooks.
usersc/scripts/token_error.php allows the end user to describe a token error however they want or even to redirect.
usersc/scripts/during_user_creation.php allows users to either process additional form fields or basically do anything just before the user creation process ends.

usersc/scripts/additional_join_form_fields.php allows the user to add additional fields to the join form without moving the whole join form to usersc. Example code is inside.

All token doesn\'t match errors have been removed in place of the usersc option.

Fixed language error on email_settings.php

I noticed that there are only 13 forms using the token system. We should probably go back and fix the others.
  Reply
#2
Question: What kind of solution or alternative is there to the token system? I personally hate that I can't open and submit both forms at once...thoughts?
  Reply
#3
You should be able to assign the token to a variable outside the form and then just put that variable in a hidden form field in each form and do the check as usual.

The key is to only generate the token once per page.
  Reply
#4
Generally anytime I load another page with a form one of the two will fail because of the token being generated on every form load...are you suggesting I generate the token elsewhere? Wouldn't I still have this issue though?

Also, I pushed my final branch. I have tested everything, everything is working and I made final adjustments.

My only last thing I want to do is a password history option - but is this even possible with salt/hashes? Because of the salt aren't no two password hashes the same?

58 users/admin_logs_mapper.php Public
57 users/admin_logs_manager.php Public
56 users/admin_logs_exempt.php Public
55 users/admin_logs.php Public

Need to be added as private admin only.

BUILD NOTES STATUS 22

UPDATES
users
profile.php - Added line break after "All Users"
mqtt_settings.php - Added line break after "Add MQTT Server"
verify.php - Added logger
verify_resend.php - Added logger
forgot_password_reset.php - Added logger
email_settings.php - Added line break after submit buttons

No SQL, branch is committeed and pushed.
  Reply
#5
Also: I keep forgetting...
We need to add a setting for notification timeout, and default page security (public or private).
  Reply
#6
Can you add those to the doc?

It pretty much breaks all security if we ever know the password.

Even if we only store the password when they change it (ie, they enter their old password, it confirms it, then we store it), that's pretty dangerous because of the way people reuse passwords. I guess technically we could store the bcrypted old one too, but I still think it's an issue.


Awesome. We'll get your stuff out. 4 alphas in 1 day. That's progress.
  Reply
#7
I definitely wouldn't want them stored plain text or in any easy-decryption way...so that kind of brings my question: is it even possible? My thoughts with that is just to allow US admins to have a "user can't use last x passwords or any password within 12 months" or something...Facebook can do it safely! Why can't we?! Lol
  Reply
#8
Yeah. We can. We make a previous passwords table and when they go to change their password, the act of entering the current one adds it (bcrypted) to that table.

About a month ago NIST revised their recommendations for passwords suggesting that people stop making people change passwords that haven't been compromised because it leads to weaker passwords in the long run...
http://fortune.com/2017/08/07/password-r...haracters/
  Reply
#9
I'm not suggesting to require regular password changes - just to store previous passwords based on the US admins set criteria, but thanks for the article, I think I remember reading that!

With this though: we would also need to consider the forgotten passwords.

I think this is more of a US5 feature.

I also added those to the to-do list.

I think we're almost done!!!!!
  Reply
#10
Generally anytime I load another page with a form one of the two will fail because of the token being generated on every form load…are you suggesting I generate the token elsewhere? Wouldn’t I still have this issue though?

The token system doesn't technically care where the token is generated, but you do have to make sure it's after post.

So, if your page is
headers/includes
$_POST
Form1
Form2

You can do
headers/includes
$_POST
$token = Token::generate
form1 (with $token in a hidden field)
form2 (with $token in a hidden field)

The big thing people do when they try to generate the token outside the form is that they put it before $_POST so the token changes JUST BEFORE $_POST is read.

Since php reads the file in order, you submit the page, it reads the headers, processes post (including the token) and then generates a new token without breaking the old $_POST.
  Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)