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 028 - Progress
#51
Ok. Sounds good. Just checking to make sure I didn't overstep.
  Reply
#52
Oh gosh don't worry about that! We're contributing, you're the project manager per say! When you going to push a new code would love to hammer at it for the day?
  Reply
#53
I just pushed out some code. There is a fix for the db import, new db dump, and I added oneclickedit to some of the admin_menu stuff.

I'm about to tackle the vericode and forcing the "order" on the menu to be an integer in oce.

what do you want to work on?
  Reply
#54
I don't know there is much more I'm good at doing! Lol

@karsen had mentioned the ajax username check and password system I don't know if that meant he was going to do it or just mentioning it...not sure I'll be any good at the ajax part...
  Reply
#55
I'm horrific at ajax. I break it all the time. I'll work on my oce parser file first and see what happens.
  Reply
#56
I do however think we're almost ready!
  Reply
#57
We are definitely getting there! Do you want to make the enable/disable db menus feature?
  Reply
#58
Hmm. So I had a thought. Since the user doesn't have to login in order to use the vericode system, someone could basically put whatever they want in the url and DOS attack the system to lock users out. Basically you could keep requesting password resets with random vericodes to get the system to lock out a particular user. That could be bad.

So that leads me to a bigger picture thought. With all this logging, I wonder if we want to create a banned ip list and ban the ip instead of the user. We'd also need a whitelist though because I have a static ip for my company, so if someone just screwed up inside the office, they'd lock out the entire office.

I'm not sure that there's a great way to do this that doesn't cause more harm than good.
  Reply
#59
Banned IP would probably be best tbh...

Whitelist yes would be necessary.

What about Session ID?

We've recently done a lot of fraud work at our company lately and one thing we've noticed is Fraudsters don't worry about changing a session ID (clearing their cache and stuff)...that might be best practice...
  Reply
#60
Also: How do you want the active/inactive formatted? Do you want it on OCE format or on the menu item page?
  Reply


Forum Jump:


Users browsing this thread: 4 Guest(s)