| User | Post |
|
11:41 am
April 1, 2010
|
Clicker
| | US-Arizona | |
| Member | posts 11 | |
|
|
Post edited 12:05 pm – April 1, 2010 by Clicker
Priorities as I see them:
1. Setup forum as the sole login across the site (primarily Wiki for now — currently no other components need a login, but this may change in the future). EDIT: Issue 1 with single sign on: Usernames *may* be different between forum and Wiki, if they are, it would be difficult to bring the necessary data over and map between the two tables/databases. If usernames are the same it would be easy. If there are any different users this issue can be fixed, I'd just need each users name in the forum and the Wiki.
2. Issues/Voting system. I see this having ties to the forum to add comments (also the login system as well).
3. User Permissions system. Due to the single login feature implemented in step 1, it's highly likely that there will be some issue with people editing everything. I'd suggest some kind of linear permissions based system. The permissions could be limited to just outside of the forum (I'm assuming the forum has it's own permissions system built in).
|
Computer Systems Design (IT) & Web Developer
|
|
|
11:52 pm
April 1, 2010
|
antinode
| | |
| Member | posts 64 | |
|
|
Post edited 11:56 pm – April 1, 2010 by antinode
Integrating multiple web apps to allow for single sign on and easy permissions management is something I've looked into quite a bit, and it's no simple task. Most popular apps have various means of integration but most are hackish at best. Simple:Press is a Wordpress plugin and uses Wordpress for user management. There are solutions available to allow MediaWiki to use Wordpress users, but this would get messy when trying to integrate the Collaborate Decision Tool or anything else down the road. It's not impossible but it'is not an ideal solution. Wordpress isn't intended to be that type of CMS.
It may be worth considering bringing these things together into one integrated package by porting to forums and wiki to this proposed management software. Having portal pages for missions (cstart.org/missions/cllare) and individual subgroups (cstart.org/missions/cllare/propulsion) with the latest relevant discussions, decisions to be voted upon, wiki edits, code commits, blog posts, etc, would be so much better than having to jump between multiple various standalone web apps. Rather than having a user profile for the forums, and a user talk page on the wiki, there could be a single user profile (cstart.org/user/antinode) showing the users bio, which groups they belong to, and all their recent contributions.
|
|
|
12:17 pm
April 2, 2010
|
Clicker
| | US-Arizona | |
| Member | posts 11 | |
|
|
I wouldn't expect it to be the easiest thing in the world, but I have an idea to make it work. All we have to do is emulate the same sessions that the forum (AKA wordpress) is creating for users, and integrate that session into the wiki. My plan for this would be to make a backend PHP script with some of the same code from wordpress (regarding the login code), only modified to work for our needs, and add that script as an include to each of the wiki scripts, and on the login page of the wiki we would simply redirect the login form to the forum login with a redirect back to the wiki. Or alternatively, we could duplicate the forum (wordpress) login, and add it to the wiki.
We're just looking for single sign on for users, they won't need to know how the technical details of it work so long as they can login once and be logged in site-wide. I'm not aware of any CMS's that work perfectly with this kind of setup. The CMS isn't designed to do everything, it can't be that's simply too much to ask for. This is why it's necessary to have someone with PHP experience to hack the two systems and tie them together.
Just adding my thoughts, I haven't figured everything out yet b/c I don't have access to touch anything yet and it would take quite a long time to try and duplicate this environment elsewhere…
|
Computer Systems Design (IT) & Web Developer
|
|
|
5:15 pm
April 2, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
Clicker said:
Just adding my thoughts, I haven't figured everything out yet b/c I don't have access to touch anything yet and it would take quite a long time to try and duplicate this environment elsewhere…
It would be up to Rizwan to give you whatever access you require to play around with this. I am not sure how fine-grained the access he can hand out is. If the only way to let you experiment with this stuff would be to give you complete access to the whole site and to other sites he has hosted on the same account, he might be hesitant. Perhaps we are getting to the point where we need to investigate alternative server arrangements?
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
7:06 pm
April 2, 2010
|
Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
This is definitely a stumbling block to getting the site streamlined. I personally don't have the knowledge to even attempt to solve this problem. Maybe some kind of online password manager that can log a user into different sites.
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
|
7:31 pm
April 2, 2010
|
Clicker
| | US-Arizona | |
| Member | posts 11 | |
|
|
Well I don't know that changing servers would really be necessary but we definately need to do something to move forward… I'll send Rizwan a PM soon to see what we can do… I fully understand the hesitation thing, I wouldn't give some random dude that's only been a member for a few days access to my stuff either. :)
PW manager between sites would be bad… depending on your definition of site. The way sessions work they cannot be transferred between sites (domains) so that process would be impossible, or at least require multiple logins using the same backend DB. Cookies can be less restrictive but open up the possibility to security issues by allowing other sites to read them (bad news bears).
For proper security the solution needs to be the more complicated method of somehow integrating the login systems for the wiki and forum. How it's done really doesn't matter what matters is that somehow we get both the wiki and the forum to pull it's user information out of the same table, therefore using the same username and password list.
|
Computer Systems Design (IT) & Web Developer
|
|
|
7:37 pm
April 2, 2010
|
antinode
| | |
| Member | posts 64 | |
|
|
Post edited 7:40 pm – April 2, 2010 by antinode
As I said before, there are already solutions available so there's no need to roll your own. My qualms are with having Wordpress handle user authentication. Wordpress is first and foremost a blogging platform. It has been extended through add-ons but it is not a full blown legit CMS. You're free to do it this way, but you're going to run into issues down the road when you have to integrate the custom project management code to also use Wordpress for authentication, and then configuring Wordpress to handle complex individual and group permissions. When this management software is released as open source it'd be silly to require Wordpress be a prerequisite. You'd be better off using LDAP for authentication and permissions for everything.
Or, like I said in my previous post, build blog, discussion, and wiki support into the new project so it's all one streamlined site and not a bunch of different apps that have no idea what's going on in the other apps.
For the blog posts, there could be site-wide posts that show on the home page, mission blog posts, subsystem blog posts, and personal blog posts.
For the management software, there are plenty of open source solutions similar to fork.
|
|
|
8:54 pm
April 2, 2010
|
Clicker
| | US-Arizona | |
| Member | posts 11 | |
|
|
Well you're talking about a much bigger issue than what we're currently dealing with. Obviously wordpress wasn't meant to be the end all solution for everything. But the site is already live and there is a large amount of data already in place with a system built on wordpress. So for the moment, adding wordpress authentication to the Wiki is a simpler solution than getting a whole new CMS and migrating all of the existing users/data/metadata over to a brand new CMS (plus the lead time to figure out how to migrate the data).
Why would you say that any open source solution would be silly to require Wordpress? How do you think wordpress got so big in the first place? All of the thousands of extensions made for it require it don't they?
Now maybe an alternative solution would be to get one of the wordpress Wiki's and just migrate the Wiki data over (which BTW could potentially still be more involved then just adding wordpress authentication to the existing Wiki).
At this point we come back to a much more broad question. Do we keep what we have and push forward (even if it might not be the best solution)… Or do we re-work the entire site from the ground up now? Personally I don't think rebuilding the entire site is necessarily the best solution right now, due to limited resources. I think if we take the right approach now in building the issue/ticketing system then we could potentially be in the same boat in a year or two when it comes time to migrate everything over to a new system, except that we may have more help on the web developer front.
As for LDAP authentication.. How exactly would we do that? Not that I know all that much about the configuration of the host server, but I assume that nowhere in the environment is there a directory service that can be used to query with LDAP. And even if there was, what difference does that make? We still have to process the login/security via PHP. The only reason I could ever see to use LDAP would be if we were running active directory or something similar in a corporate environment to allow single sign on from desktop to website. Otherwise there's really no difference between using LDAP or just using a regular database driven form login.
|
Computer Systems Design (IT) & Web Developer
|
|
Login 
Register 
Search 
Home
Topic RSS 
