The following warnings occurred:
Warning [2] Undefined variable $unreadreports - Line: 26 - File: global.php(961) : eval()'d code PHP 8.2.25 (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 029
#1
Hello guys,

I went ahead and pushed Status 29.

This included merging Karsen's updates he posted about in the 28 thread, and all of Mudmin's little fixes. Also includes my two file commits which I noted in the status 28 thread.

Lets begin our conversations here including:
What are we doing about more graceful token fails? Do you want this in 43 or is this US5?

Should we turn message notifications on by default? Or off? Do users setup their email settings during setup? If we enable it by default we could run into issues with email failures.

The Help menu in the DB-driven nav is set to logged in only, set this to no, we don’t want logged in users to see it, and don’t want guests to not have this menu. You also need to add forgot password to this menu.

When you remove the data in the username field it goes to “Unable to check”…we should just remove the message if the field is empty. We should also add this for email. And I would like to deploy this to admin_users.php for the manual add please.

Thanks for all the work you two have put into this - I am excited for us to get this into Beta!
  Reply
#2
I also merged @Karsen's username logic update.
  Reply
#3
Awesome. Sounds good. I'll pull. I'll do some work on the ip stuff.
  Reply
#4
I'll start on some of these things. I think we should add the graceful token fail to usersc so people can have their own idea of graceful. That should be pretty simple.

I would say off by default for the notifications. Some servers are not happy about people sending too many emails, so I think we should let admins roll that feature out when they're ready. I know I'm thrilled to have it though.

Did @karsen fix those messages in both areas?

So to summarize, I'm currrently working on ip stuff and token fails. Then I'll go over to the other stuff. I think the ip thing is going to be a decent sized system, so it's going to take a little bit.



  Reply
#5
I'm thinking this is was from one of you guys, but when I ban or unban a user, email_verified is always set to 0 and that takes precedence over the ban message. It's not super obvious to me where that's coming from.

Any ideas?

I'll keep plugging away at the other stuff.
  Reply
#6
Yes - I do think the graceful token fail should go in usersc, but we should define a default, because we need to be more graceful no matter what the user wants to change it too...I personally hate the die(), it just breaks so much imo. I know Karsen fixed it on join but I'm not sure that he had deployed it on the admin_users page (deployed the username check system at all).

The issue with email_verified was I didn't wrap the PHP in the if. I committed the change for this.

Also, your email_settings page is broken...I don't know what happened.
  Reply
#7
Absolutely. Me too. I'll take care of that.

I'll do a pull and also take a look at the email settings.

System settings on admin_user is broken too.

What are your thoughts on per page ip checking vs key entry points?
  Reply
#8
Actually, I already did the graceful token error. It's in usersc/scripts/token_error.php
  Reply
#9
There's nothing in system settings...this is meant as a custom section. I brought this up before but we never came to an agreement on it. I want to do something similar to how previously we had the admin_panels on admin.php where if the user created the file, the stuff was held within that spot, we could do that with system_settings, if the file exists, show the button, and include the contents within the modal.

I see the benefit of doing mass-ip checks for if the admin wants to ban a known bad IP address from their entire site...but I also don't want bans to occur from excessive user of other pages.

Bans should occur from:
-login.php
-join.php
-forgot_password.php
---any other page related to an un-logged in user
-a spot in the admin panel

With the ban, we can also setup a "request unban" button that sends a message to the main admin (which we can define on our ban admin page - or anyone within the admin group) requesting they be unbanned.
  Reply
#10
Ouu, much better. Can we add a logger too please.
  Reply


Forum Jump:


Users browsing this thread: 19 Guest(s)