Get multiple users security about muximux HOT 53 CLOSED

Having the ability to link it to a Domain list would be amazing but I know also a huge request

from muximux.

Please specify "Domain list"?

from muximux.

Domain list as in authentication with an Active Directory or LDAP server. So I keep 1 single list of people who are allowed to see everything (IE Admin), people who can see only PlexPy (IE Managers). Just as an example.

from muximux.

That's way beyond the scope of this project.
You're free to fork and try it yourself - otherwise I'd suggest you have a look at having IIS use HTTP Authentication with an LDAP/AD backend.

from muximux.

I'm forking this and using MYSQL to create a user database with email functions and reports... almost done... hides menus and everything based off of security groups.

from muximux.

Sounds way cool... any way you could implement the same thing without the use of MySQL or any SQL database? I'd gladly accept a pull request if we could just keep the server-side requirements as few as possible. Setting up MySQL can be very daunting for most people.

Perhaps using https://github.com/pear/Config_Lite ?

from muximux.

Lemme research that and we'll go from there. :) thanks man.

from muximux.

FYI, another dude is working on an installer and updater-thing using Config_lite, which will probably be merged to Muximux as well (https://github.com/SyNiK4L/Muximux/commits/master)

from muximux.

that's pretty sweet! i've never used Config_Lite so I will leave it up to him. It'll be way better then mine any way lol.

from muximux.

all done 👍

https://github.com/causefx/MMHTPC-ManageMyHTPC

from muximux.

Nice work, though a bit too complicated for the aim of Muximux (requires MySQL). If you happen to fiddle around with Config_Lite and want to port your changes, I'd be more than happy to merge with Muximux.

Also, in your fork you forgot the "LICENSE" file (GPL license) that Managethis implemented and Muximux adhered to which you agreed to when forking - just an FYI in case someone decides to fork your work!

from muximux.

Oh crap. Forgot that. Thanks mescon... Yea I will probably go the config lite route if that guy that forked your repo doesn't finish it.

from muximux.

You could try implementing with sqlite instead for an intermediate solution. It is small and file based, or for that matter just utilize an apache auth_basic password store

from muximux.

Lets wait a minute and see what @SyNiK4L comes up with so that we don't end up needing support for both Config_Lite and mysqli :-)

from muximux.

I agree with that. On standby

from muximux.

Well what i'm writing is definitely only going to currently support changing configurations. It's not going to allow for multi-user support. What I'm aiming for is to not require people to understand how the config.php.ini works and just have a menu to allow managing that. So I feel like we're talking about two different things here. I agree with mescon that it would be kind of adding more confusion for most people to use the database route. I myself would love it, but thats coming from a dev. The other option is releasing two versions. One that can use mysql(and my config lite config editor). Then another one that is just mine for less skilled people.

from muximux.

I'm going to install yours real quick causefx. Just wanted to see what it looks like. I love the database side of it. I mean doing this config stuff would be SOOO much easier if I could use a database. Although I completely understand wanting to keep it simple. For some people making a database is a hard task

from muximux.

Also @causefx, I noticed you're using "php gettext" and "PDO". It works when you turn php get text off like you explain. As I didn't have that extension installed on my server. Although, i'd almost recommend sending it with it off. Get text is not an extension that is installed by default, and neither is PDO support.

I even have a WHM/CPanel server and I had to compile Apache with PDO support to be able to do the database setup step. I realized I needed to install PDO by looking at the unhandled error messages.
(Fatal error: Class 'PDO' not found in /home/coreyjon/public_html/muxiSQL/install/index.php on line 67)

Most people would look at that and say "what the hell does that mean lol"?

People don't have access to recompile apache on shared hosting. Also, most don't have the skills to do something like this. People we're confused about dropping static files onto a webserver and updating a config file. Not trying to knock you for at all. I love the database idea and I have no problem installing those extensions. Although, this is way beyond the knowledge of a lot of people that would use this.

from muximux.

@SyNiK4L you're absolutely right. I'll take care of that on my end.

as far as the DB route, i assumed (bad part on me) that someone who would need this type of access prevention would kind of know what they were doing if they needed it. Would adding the config lite config editor be an easy task to add to what i have compiled already? i know sucks doing double the work and such.

nice chatting...

from muximux.

@causefx Let me look and see. I would imagine it should be fine. All I did was make another page that loads in the dropdown called settings. That just edits the config.php.ini using the config lite class. So I just need to look at what you're doing a bit more and see if I can make the settings page only pop up with admin rights only. Or integrate my settings page into you're login system. Also would like @mescon to let us know his thoughts. As we forked his project. So if we're going to the pull request route. We're going to have to leave it up to him on whether he wants both systems in. At any rate. I'd like to make it as simple as possible. So maybe making two builds would be a good idea. As long as we explain what each build does and advertise them both together.

from muximux.

Also @causefx did you write that login system or just find it somewhere. It's pretty nice and you threw it together fast.

from muximux.

@SyNiK4L I completely agree. @mescon can let us know....

As for how for adding it to the drop down, would just need to do 2 things:

Muximux.php

From...

            if(isset($_SESSION['jigowatt']['username'])) {
                $loggedin = "<li><a data-content=\"profile\"><span class=\"fa fa-user\"></span> ". ucfirst($_SESSION['jigowatt']['username']) ."'s Profile</a></li><li><a data-content=\"admin\"><span class=\"fa fa-rocket\"></span> Admin Area</a></li><li><a data-content=\"logout\"><span class=\"fa fa-close\"></span> Logout</a></li>";
            }else{
                $loggedin = "<li><a data-content=\"login\"><span class=\"fa fa-key\"></span> Login</a></li>";
            }

To:

            if(isset($_SESSION['jigowatt']['username'])) {
                $loggedin = "<li><a data-content=\"profile\"><span class=\"fa fa-user\"></span> ". ucfirst($_SESSION['jigowatt']['username']) ."'s Profile</a></li><li><a data-content=\"admin\"><span class=\"fa fa-rocket\"></span> Admin Area</a></li><li><a data-content=\"edit\"><span class=\"fa fa-gear\"></span> Edit Tabs</a></li><li><a data-content=\"logout\"><span class=\"fa fa-close\"></span> Logout</a></li>";
            }else{
                $loggedin = "<li><a data-content=\"login\"><span class=\"fa fa-key\"></span> Login</a></li>";
            }

config.ini.php

Add:

[edit]
login = "true"
name = "Edit Tabs"
url = "edittabs.php" ; or we can add to admin area or something
landingpage = "false"

from muximux.

it was an existing login system that has been out for years.

from muximux.

@causefx Gotcha. Then yeah it should just fit right together with that one modification. Then also block the settings menu from direct access. Which should be easy.

from muximux.

Nice. It's pretty sweet.

from muximux.

yea, would be so easy... with the script

from muximux.

Yup. So i'll be working on this today and tomorrow. So hopefully I should have all my bugs out by then. At that time we can make another build on a separate branch. Then merge the two and see how it looks. I just wanna get the bugs out of mine first. It's a bit weird how this whole writing to a config works. So it's taking a bit of time to get all the weirdness/bugs out. Super easy to read, but damn writing is a pain.

from muximux.

Not to discourage in any way... following this project (and using it as of recently). Have you considered ditching .ini for JSON? I had a similar project where the INI was getting a bit out of hand, and I decided to switch to JSON as my on-disk config file and my life got a lot easier. Just a thought.

from muximux.

@evanmj i myself havent, but maybe @SyNiK4L has and can.

from muximux.

@evanmj. Hmm. I do like that idea. I didn't think about that. I'ma think about swapping to that route. Although. because technically i'm almost done. Wondering if it would take more time to rewrite or to just finish what I have so far. I'll reassess here in a bit.

from muximux.

Sure- Maybe finish this feature, and make it a new feature to migrate to JSON. There is nothing wrong with INI, and it is actually a bit easier for a user to hand-write... Just a pain to work with sometimes.

from muximux.

@evanmj completely agree lol.

from muximux.

yea, but if we use Config_lite to write, the user will be ever so happy :) 👍

from muximux.

True that.

from muximux.

Hey everyone - it's awesome to see we're all working on this together - I'm stoked!
First, let me be clear - In no way, shape or form do I want to "hog" this project and call it "mine", because it really isn't - it's ours, and I do mean that.

If you want to, you can all have admin access to this project - the only reason I haven't invited anyone yet is because I want to make sure that this URL that people are doing git pull from is somewhat regulated and managed, and doesn't make sweeping changes without communicating it to users first.

I have no inherent love for INI files at all, and if it turns out to be too much of a pain to deal with, we'll absolutely go another route, though one thing I really want to strive for is "KISS" (keep it simple stupid), at least in the way that users of Muximux can interface with the installation, administration and usage of the application.

I myself would probably have gone the SQL route, but then I thought about aaaaaaallll of the support questions being asked Tenzinn3 who made the static HTML Managethis, so I thought "Hm, OK - we want to build something more dynamic, but that is still really easy for people to edit by hand themselves". Going the SQL route would require installation, configuration and maintenance of another set of software, which would defeat the goal of keeping it as simple as possible.

Another big thing is keeping the setup requirements as few as possible - perhaps only to "webserver with php" and nothing else if feasible from a development perspective.

If we get an installer working, a nice user interface to manage settings (like what @SyNiK4L is working on, perhaps styled with the use of bootstrap modals the same way manage-this-node has done here we might not need to convert the backend to JSON simply for the sake of it. If, however, the project grows beyond the current pipeline - ditching the ini is no big deal, as long as we have a functioning and easily grasped "settings" menu.

Currently in the works either by @SyNiK4L, myself or other contributors is:

• Settings menu to edit urls, dropdown menu items, icons and whatnot
• Version management - step one is to show current version compared to the latest commit on Github, the next step is to allow for an update if git is usable by the webserver and the directory is writeable.
• User management (different menus for different users) - this was completed by @causefx though the imlementation defeats the goal of simplicity.

So far, things are progressing nicely (at least from what I'm feeling - I don't know about you guys?).
It is my hope that we don't fork off too much just to do different implementations of the same thing, so I'm more than happy to see pull requests coming to Muximux and let the current user base see the benefits of our combined work, without having to inform themselves of 5 different forks and what the pros and cons of each are. Fragmentation can be a bitch sometimes :-)

I would love to hear your reaction/thoughts/concerns over my reasoning above!

Cheers!

Ps. Perhaps I should write a "CONTRIBUTORS" file to keep track of the good people that developed Muximux?

from muximux.

@mescon TL;DR! LOL just kidding... nice write up. And i know exactly where you are coming from. Honestly i havent wrote code in a very very very long time. I built and used to run a quite large website a few years ago called... iCauseFX.com - which was an iPhone Cracked DB... shut it down a while back due to being paranoid lol.... I just recently got back into usenet and started installing all the apps and stuff and came across managethis and then saw your fork... Needless to say you got me back into coding haha... anywho....

my reaction: lets do it! i'll research some local db functions or just readup on Config_lite to see if it allows writes and such.

from muximux.

Just make sure you don't reinvent the wheel in case @SyNiK4L has already got the writes working nicely!

Also - what the hell man, you took a day and came back with full SQL integration, administration and user management... we're all more or less doing this just as a side hobby, so don't put yourself down!

Hell, it took some courage to even show all of you my weakling spaghetti code, but what the hell - as long as we're having fun, right? :-)

from muximux.

Yeah it does. That's what im using to write. I am pretty much completely done. It reads it writes. It saves perfectly. I just want to do a bit of cleanup tonight/tomm and i'll be good to go. It works pretty much perfectly right now. So the only thing I have left is things like that random case where "person x did y" and it broke because this didnt exist or that wasnt set. I should be able to easily drop it into the login system. @mescon what did you think about the multiple build idea. We'd show them together and explain the differences. That way for those that want the easy drop in method, they have that. Then the people that want the more advanced route they have all the normal stuff and the db side of things.

from muximux.

Haha yeah all of this is for fun. Shit I do have of this while I'm at work. I'm just having fun. I'll just wait for him to be done and then see what he has

from muximux.

@causefx same here rofl

from muximux.

And I really like this https://cloud.githubusercontent.com/assets/5875228/12495727/a56b0ef2-c091-11e5-8761-776fd15179d7.png

I definitely think once I have this side of it done. We can redo the css with the bootstrap styling. i like that way better than mine.

from muximux.

Same here guys... I don't think I've gotten much ACTUAL work done the last week or so :-)

@SyNiK4L As I typed in my HAWOT (Huge Ass Wall of Text), I was hoping we don't create forks of forks of forks, where the user doesn't get X that was developed for fork Y - so hopefully we can all keep it together.

from muximux.

I gotcha. Okay just didn't know if you were including that or not

from muximux.

cool cool! I'll await when you merge the pull request, then we shall go from there.

from muximux.

Okay sounds good. Im thinking tonight or tomorrow. Ima try to ignore the girlfriend and keep plugging anyway. Im pretty close.

from muximux.

Guys, I created a Gitter chat room which seemed more appropriate for chatting - come on over when you're up for it!

https://gitter.im/mescon/Muximux

from muximux.

howdy, jayrox here (one of the contributors to the node.js fork) glad to see the hugely open dialog here that is clearly in the spirit of sharing. this makes me happy to see. i'd be a liar if i said i didn't peek over here at least once a day to see how you guys are progressing and seeing where your changes could benefit the node fork also. glad to see you guys are doing the same.

from muximux.

Cross pollination ftw!
Have a look at 59f001d which I think is a good, simple fix for something I'm sure the users of manage-this-node would be thankful for :-)

from muximux.

i was looking at that last night. still an issue for sites that use X-Frame-Options: DENY

from muximux.

Some quick googling came up with this:

http://stackoverflow.com/a/25587483

An alternative would be to use "loadframe.php" which opens the remote URL and serves it, while at the top setting a broken header like so: http://stackoverflow.com/a/6767901
I don't know what implications that would have on the iframed content though.

from muximux.

yeah, i saw that but was hoping to find a method that doesn't MITM the iframe contents

EDIT, forgot the negative

from muximux.

Let me know if you find anything, I'd appreciate it. I'll do the same if I
find something.

from muximux.

Will do

from muximux.