Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - roastchicken

Pages: [1] 2 3 ... 32
Off-Topic / Re: Learning Python
« on: Yesterday at 10:24:34 AM »
I'm a bit late, but I'd hazard to say that most web languages are going to be inconsistent due to the need for backward compatibility and the huge scope of devices and services they must serve. JavaScript is also (in my opinion) disgustingly inconsistent, but it's the best (if not only) solution for browser client side scripting.

Releases / Re: Two-Factor Authentication
« on: January 12, 2017, 10:27:08 AM »
I was going to post this 8 days ago, but I was busy and I forgot about it. I thought I had more to add, but I can't think of it now. Maybe it will come to me later.

Quote from: roastchicken date=1483552800
Ironically, your failsafe introduces a couple of new exploits.

First of all, you never do any verification in the 'Hack Ban' net message. Anyone with the ability to maliciously send the 'AddMeToMyRankPls' net message would be able to maliciously run the 'Hack Ban' net message. Sure, they can't set their group, but they can ban anyone they want to.

Now, I've thought about it for a tiny bit and I can't think of a way you would be able to verify this, at least not in a way that would work with your current use. So this brings me to the second exploit:

You're having the player send the net message that is going to get them banned. Assuming they're in the GUI for malicious reasons, they've probably seen the code for this addon. Which means they've seen that opening the GUI is going to get them banned. If I were in the shoes of a malicious player who wanted to view the GUI and not get banned, I'd just detour that net message. The key phrase when working with net messages is never trust the client. Just like you can't trust a client when it sends a net message, you can't trust a client when it doesn't send a net message.

A possible solution to this is to verify with the server before running the code to display. Create a concommand on the server and do all the verification stuff to make sure the user should be allowed to view the GUI before even opening it. Better yet, do away with the roundabout concommand stuff and just send a net message to the client that opens the GUI when they connect and the proper requirements are met. This way you won't need a net message to ban anyone, which means no net message to exploit.

A few miscelanious things to think about:

Why do you declare TFA.HackBan if all it does is call ULib.ban with the exact same arguments? Why not just call ULib.ban directly?

Why are you banning people for viewing the GUI? Is there something the average user shouldn't see in the GUI? If there is, maybe you should remove the sensitive information or think about making it more difficult to access rather than making it open via a console command. I know that I sometimes snoop around with autocomplete to see what commands I can run, and with this system in place doing so would be the death of me (a bit melodramatic, I know  :P). I didn't do anything wrong other than run a command; how was I to know I wasn't supposed to run it or that doing so would get me banned for a week. And finally, anyone attempting to exploit this probably knows how to view any clientside lua files downloaded from a server, so they're going to see the code for the GUI at the very least (and also the rest of code, but I'm not sure that's much of a disadvantage. Plus, it's a topic for another time).

Ultimately, you're fighting a losing battle trying to prevent them to view the GUI. If you send something to the client, someone is going to snoop through it. There's nothing you can do to stop a determined individual from seeing clientside code.

Let me know if you'd like more information. If I have time this weekend I'll try to submit a pull request with the way I would solve this exploit, but whether or not I'll have time is questionable.

Off-Topic / Re: Learning Python
« on: January 09, 2017, 12:01:00 PM »
I second JamminR's suggestion of PHP, it's a pretty neat language. I only have minimal knowledge of it, but it's probably the most used language in terms of server-side scripting. If you ever plan on doing web development it's a useful skill to have.

However you should definitely stick with Python for the time being unless you're infinitely more interested in web technologies, as Python seems to have more applications than PHP.

I've always wanted to learn more languages, as right now I only have a rudimentary grasp of JavaScript in addition to my knowledge of Lua. Learning C++ is one of my goals, but it's such a shift from a lightweight scripting language such as Lua.

Developers Corner / Re: XLib Documentation
« on: January 09, 2017, 11:53:24 AM »
Again, please provide me with any errors and the full files those errors point to. Without this crucial information any help I give is just guesswork. I'm still skeptical that your issue is with the Add line, but I can't weigh in further without the full file so I can look at the corresponding line numbers.

Releases / Re: URM - User Restrictions Module for ULX
« on: January 09, 2017, 11:50:34 AM »
I can confirm that uppercase letters in addon names often cause issues on Linux servers. Even if it doesn't turn out to be the issue, it's better to eliminate it as a possibility.

Developers Corner / Re: XLib Documentation
« on: January 06, 2017, 10:05:20 AM »
I'm not sure what your issue is. Are you still having errors?

General Chat & Help and Support / Re: Has access to: UI gone
« on: January 04, 2017, 02:16:19 PM »
Is it just my crappy WiFi, or are the images not loading for other people too? I'd like to help with this issue, but it's a bit difficult if I don't know what's going on.

I fixed those issues but this issue was happening before these commands were added, any ideas?

Could you show us what your new group structure so we can verify that you have in fact fixed those issues? I don't mean to call you a liar; it's easy to make mistakes and I want to eliminate as many possible causes as possible.

I'm sorry but we can't help you if you didn't make backups of your original working data we have little idea from the conscious stream of information you've given to us what your problem may be but we will have to recommend following the following FAQ answers in order, if the first Factory Resetting ULX/ULib Installation doesn't work then try moving on to the next How do I make myself admin? (3 simple foolproof methods) and then if those can't or don't help then How do I uninstall ULX/ULib? and reinstall in TWO separate addons folders as combining them into one folder DOES NOT save space and makes updating difficult which may actually cause issues if one got updated but not another then scrambled code could happen oh and you didn't answer the nice little template we have when posting new topics in this section so we have no further ideas because you didn't answer important questions but instead erased them

Where'd the red go? >:( >:( :-[ :-[ :-\ :-\ :'( :'(

Developers Corner / Re: XLib Documentation
« on: January 04, 2017, 01:56:02 PM »
I don't think it's that line. The error references RemoveLine, but the line you're saying is causing the error doesn't remove a line; it adds one. My best guess is that it's the next line, but I can't be sure unless you give me the entire file so I can cross reference the line numbers. I'm on an airplane now, posting this via the in-plane WiFi (painfully slow in-plane WiFi, might I add. But I am on a plane, thousands of feet up in the air, so I'm not sure why I expected better), so I can't test what DListView:GetSelected returns. But my guess is that when it returns a table of the lines (according to the wiki), it's not returning a table of the line numbers. I'll do some spelunking in the code for DListView to see what exactly GetSelected returns and how to get the line number from a line (because it doesn't seem to be documented in the wiki) and get back to you.

edit 2: The magic of GitHub strikes again. If the version of DListView_Line on GitHub is to be trusted, then you should be able to do something like Line:GetID() and supply that as the argument to DListView:RemoveLine(). I should probably be a good citizen and document this on the wiki, but I'm lazy and not looking forward to waiting for the page to load on this slow WiFi. Maybe once I get home.

An additional, less important, fact is that DListView:GetSelected()[1] is identical to DListView:GetSelected() (according to the wiki, at least. It's proven to be less than accurate in the past, but usually pretty good).

edit: Looking back at the previous replies, I'm very much confused what this has to do with XLib or making things invisible.

You'd also likely want to check, the way you're currently checking, using ULib's GetUserGroup.
I'm not sure your GetNW string would work consistently or at all.
If you don't use ULib, unfortunately, GMod's closest check is Player:IsUserGroup. With that, you'd have to do a for loop through your table checking if player was part of the table.

Garry's Mod actually has Player:GetUserGroup by default, and has had it for some time actually (I wonder if I could have used more conjugations of 'have,' or more 'actually's). I just found this out after I recently went spelunking for such a function in vanilla Garry's Mod because I was too lazy to install ULib. I don't know if networked strings are case-sensitive, but the default implementation of Player:GetUserGroup is almost identical to what VORTEXGaming is doing except for the casing and the fallback:

Code: Lua
  1. function meta:GetUserGroup()
  2.     return self:GetNWString("UserGroup", "user")
  3. end

@JamminR What is the correct Code then?

Take a look at the documentation for hook.Add() that JamminR has so kindly linked to. It includes some examples that show you how to run code using hooks.

Let me know if you need more hints.

I need to test the command first to get some insight as to why it isn't doing as you intend before answering your first two questions, but I highly suspect the reason is because you're passing openedurl (which I assume is a string) and target_plys to ulx.fancyLogAdmin() while you only have one thing for it to replace, #T.

not really an edit: Something I just realized is that you only have one argument set with cmd:addParam(), so openedurl will always be nil. This could also cause problems with fancyLog.

As for how to make the image pop up without you being able to close it, you'll most likely need to create your own custom menu.

And as a final aside, some unsolicited advice: making an image pop up on player's screens without them being able to close it is a good way to get them to leave your server and never come back. At least, that would be my reaction to this if I had recently joined.

edit 1:

I think BlueNova had a good idea with separating the commands, as setOpposite isn't really intended to be used for silencing commands, but at the same time that issue could be fixed (I'm 99.9% certain, at least) while keeping them combined.

edit 2:

I guess I didn't read your second question correctly the first time around. I don't believe fancyLogAdmin accepts color arguments, so you'll have to use ULib.tsayColor.

Developers Corner / Re: XLib Documentation
« on: January 01, 2017, 02:23:45 PM »
Can you give us a code snippet to show exactly what you're doing?

Developers Corner / Re: XLib Documentation
« on: December 31, 2016, 04:19:21 AM »
What do you mean by "hide fully?" Isn't making them unselectable and invisible hiding them fully?

Those pages seem to do most, if not all, of the processing server-side. They just take some text input and return an image. If Awesomium doesn't agree displaying the webpage, it'd probably be possible to just http.Fetch the image.

Could you supply us with the console logs of a server startup?

Pages: [1] 2 3 ... 32