New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
We have actually updated those fields to be more meaningful. It is actually the provider's website URL. So if you click on their name it will take you there - for convenience. You can use either their main website, or their control panel URL - or keep it blank if you prefer.
I am pushing some changes right now to develop branch. Once tested it will be merged to master.
Thanks.
well.. it's error if provider url is blank
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'provider_url' cannot be null
Yes, in the master it was actually required. This is why we introduced a fix to make it optional - however this is in the develop branch - which will be pushed to master after testing.
ok. sound good.. keep hard working sir
I read over your code and just one comment...
Have you thought about sanitizing your input?
Best sanitation method is (In my and countless other professionals)
strip_tags(htmlentities($input))
Make the input sanitization a middleware. I think laravel has a sanitization middleware you can already use or you can make it yourself, pretty simple. I have one made for Slim3 but not Laravel.
At the moment, vmDash is a single-user environment (where only admins themselves can input data). Your comment is appreciated for future versions of vmDash when multi-user support is released.
However, people might have different opinions on this, but I think sanitization should be done when outputting data instead of input. I believe that data should be stored in the database as is (without modification), and sanitized to prevent attacks on output. In terms of vmDash, data is already being sanitized on output by the blade templating engine.
Thank you for your comment. I would like to hear any comments users might have on this.
Worst sanitation ever. I cannot overstate how bad it is.
Exactly.
You only sanitize input to make sure it doesn't have invalid characters that cannot be stored in your database encoding. If your database is utf8mb4 you have nothing to worry about.
Edit: I googled it and talked to some people seems like the write thing is
filter_var($input, FILTER_SANITIZE_STRING), as strip_tags doesn't remove the tags completely. But shouldn't you sanitize any input a user gives no matter what though? And not rely on sanitizing it on the output? I get that if you use parameters while inserting into the database and what not, there isn't a real threat. But still for good measure, and who knows if there might be an exploit in the future, shouldn't you sanitize all inputs? That's just my two cents. Why sanitize on output when you can just sanitize on input and not worry about it later?
PHP Filters.
No, I'm dead serious. I'm willing to explain in detail, however I should ask, why do you think strip_tags and htmlentities is a good sanitation?
Also, user input sanitation is a rookie mistake. You only sanitize an input when you will use it, or when you know the exact limitations. With a sanitization like yours, for example for a forum like LET, I cannot register with a username like Harzem the < conqueror > can I? Because you paranoidly sanitized my input and removed the harmless < conqueror > tag.
Instead you save it as it is without any sanitation, then output only using htmlentities on HTML. If you will use it somewhere else, like exporting for an excel document, you do not use htmlentities because you don't need it.
But if you made the rookie mistake of sanitizing the input, you would not only lose half my input, you would also sanitize it only for html output. Not for any other type of output like Json or Url encoding.
Also, there may be several ways of inputting data, not just user input. You may collect data from the user, or through an API, or someone may manually add the data to the database, or an integrated third-party software may modify the database. If you sanitize user input, you will leave a bunch of other ways that accepts insecure data. But if you accept the data as-is, and sanitize it only when you will output it, you don't care about the data source, they will always be accepted as-is and printed out securely.
Sanitizing user input is a very bad way of dealing with security. If I see a software doing that, I'd think it was coded by a first year newbie developer with no vision.
Laravel blade templating , when outputting data with {{}} is auto escaped, at least based on the documentation. Using {{!! !!}} would print the data without escaping. Additional measures are always recommended. IMO there should be input sanitation too for data that we know before hand that is supposed to be only numeric or alphanumeric (no symbols). Worst XSS is the one that is stored, always there waiting for you to fuck up.
So yeah while Mr. Harzem is pretty much right, you should check your data before saving too, depending on the type of data expected. But always escape before doing output.
Almost, it's
{!! $var !!}Yah exactly, I'm assuming he knows what these tags are, I mean he is using Laravel. Thanks for the correction.
Checking data (numeric, etc) is called input validation not sanitation. It's completely different. Validation is independent of the data source and output medium. Validation is done on input. Sanitation depends on output medium and done during output.
When you stop measuring dicks and yarayara, we can agree it all comes down to the same purpose, works towards the same end, data integrity. If the developer have a great input validation procedure, the risks of XSS are also minimized. Blindly saving everything to the database with PDO and calling it a day is a terrible practice.
You are not the one I'm measuring it with
I just want newbies to have some technical jargon to further research. The difference between validation and sanitation, while working for the same goal, should be seperated with great care.
Input validation and XSS is actually unrelated, and trying to prevent XSS using input validation is bad practice. XSS should be prevented on output, and output only.
No, it’s everything but bad practice. Seriously, only dumb wp plugins and government projects use strip_tags on input.
If I need to explain some HTML in a plaintext comment on a website then I can’t because it’s cluelessly stripped out. Just use
htmlentitiesor the common shorthand helpere.At my last job you wouldn’t have been hired if you argued that not using strip_tags on input is bad practice. But to each their own I guess...
Yea, just start saving all user submitted unsanitized and unfilterred data to database... That's idiotical. Filter and sanitize input and sanitize output one more time. Healthy paranoia is a benefit in this case
Input validation wouldn't do a strip or escape. Your test would return a "didn't pass" result with an error stating the issue with the data and you would display that somewhere in your form. For example, asking for a phone number or age, then a number is what should be there, different from that is an error, should not accept it.
But if you want to escape it? do it all you want, sometimes best practices are not enough. I cant imagine anybody putting script-Jorge-script (btw joke ruined by Cloudflare) in a first name field, unless if @WSS or @Deank . You shouldn't accept that in the first place, but if you escape it, you had your reason Kappa.
But yeah two different processes (input validation, output sanitation) , different objectives, same end, necessary in all projects. Laravel do some of that for you but is not considered enough. Like somebody said... you would setup some middleware to do it for you.
All jokes aside, we all have a PHD of the PHD in Computer Science so we are all correct.
We are missing the goal of this project... is for a single user. So I doubt anybody would ... XSS themselves and again if using Laravel 5 with blade chances are is already sanitized, unless using echo.
Have a nice Weekend people.
where i can get this server manager module on github or is it support virtualizor too ?
Nice job! If it is a software, I will pay for it.
This is almost 3 years old without update... Don't expect too much. Providers API may have changed during the time.
Vmdash is long time dead. To use it in production is ridiculous. And it is not a module, it's dashboard with different api's. There was saas for managing multi vendor vps can't find it, probably already flip flopped.
Although there were no updates during all that time, we are still using it - the providers API are still working as expected. Just needs updating the packages, and that is easily done in one command.
https://github.com/myrsk/vmdash
I will update the repo as soon as I get the chance.
thanks lot i will wait also other news anybody know virtualizor anybody have api interface create delete reboot etc ?