Menu
▾
▴
phpwiki-talk
|
From: aphid <me...@ap...> - 2002-09-26 17:40:00
|
i've been playing around with the most recent build to see if i could get userauth working.. i'm getting: lib/WikiUser.php:216: Warning[2]: LDAP: Unable to perform the search: Can't contact LDAP server lib/WikiUser.php:217: Warning[2]: ldap_get_entries(): supplied argument is not a valid ldap result and then 'invalid password or userid' whenever I try a login. i'm not totally clear on what LDAP is or why the wiki is choosing to try LDAP rather than the external auth db I set up. is there a place I'm not seeing in the index.php that tells it which method is preferred? cheers a |
|
From: aphid <me...@ap...> - 2002-09-26 20:59:36
|
On Thursday, September 26, 2002, at 10:40 AM, aphid wrote:
>
> i'm not totally clear on what LDAP is or why the wiki is choosing to
> try LDAP rather than the external auth db I set up. is there a place
> I'm not seeing in the index.php that tells it which method is
> preferred?
>
followup, i think I've sucessfully disabled LDAP, but now I'm not too
clear on how to properly direct it to my external db auth.. I don't see
anything in the flavor of:
if (!defined('ALLOW_EXTERNAL_DB_LOGIN))) define...
(as IMAP and LDAP are formatted)
I've set up the DBAuthParams, but I don't believe it is attempting to
connect.
cheers
a
|
|
From: Reini U. <ru...@x-...> - 2002-09-27 16:11:21
|
aphid schrieb:
> followup, i think I've sucessfully disabled LDAP, but now I'm not too
> clear on how to properly direct it to my external db auth.. I don't see
> anything in the flavor of:
>
> if (!defined('ALLOW_EXTERNAL_DB_LOGIN))) define...
> (as IMAP and LDAP are formatted)
>
> I've set up the DBAuthParams, but I don't believe it is attempting to
> connect.
It's not in CVS yet. I'm currently testing it.
I'll commit tommorrow.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Joby W. <joby@u.washington.edu> - 2002-10-02 06:53:23
|
Reini, Since you seem to be heading up the modifications to the user authentication system, I thought I would run by you two more options I would like to add. 1) a new login method (currently PUBCOOKIE_LOGIN): this will allow end user to use the University of Washington's Pubcookie system. When using Pubcookie the end user accesses a web site he is forced to authenticate at a central site, and the central login site then guarantees the authentication to the web site. Thus the end user's password is never available to the web site, and allowing a unified login structure for an organization. The only check is that $HTTP_SERVER_VARS['REMOTE_USER'] is guaranteed to be set and correct. 2) no admin account (ADMIN_GROUP): this would grant to specific users WIKIAUTH_ADMIN privilages. With this enabled there is no admin account, but certain users have administrative privilages. With this modifications can be tracked by user. jbw |
|
From: Reini U. <ru...@x-...> - 2002-10-02 09:14:23
|
Joby Walker schrieb: > Since you seem to be heading up the modifications to the user > authentication system, I thought I would run by you two more options I > would like to add. > > 1) a new login method (currently PUBCOOKIE_LOGIN): this will allow end > user to use the University of Washington's Pubcookie system. When using > Pubcookie the end user accesses a web site he is forced to authenticate > at a central site, and the central login site then guarantees the > authentication to the web site. Thus the end user's password is never > available to the web site, and allowing a unified login structure for an > organization. The only check is that $HTTP_SERVER_VARS['REMOTE_USER'] > is guaranteed to be set and correct. I'm against adding this to the default HEAD branch of phpwiki. I know that some sites do cookie auth, and even we do it in our internal backoffice, but this is totally insecure. But I already added beta support for ALLOW_HTTP_AUTH_LOGIN which accepts already logged in users. > 2) no admin account (ADMIN_GROUP): this would grant to specific users > WIKIAUTH_ADMIN privilages. With this enabled there is no admin account, > but certain users have administrative privilages. With this > modifications can be tracked by user. This will be a PagePermission feature, once groups are ready. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Joby W. <joby@u.washington.edu> - 2002-10-02 16:07:28
|
Reini Urban wrote: > Joby Walker schrieb: >> 2) no admin account (ADMIN_GROUP): this would grant to specific users >> WIKIAUTH_ADMIN privilages. With this enabled there is no admin >> account, but certain users have administrative privilages. With this >> modifications can be tracked by user. > > > This will be a PagePermission feature, once groups are ready. Any info on this? I will certainly help. jbw |
|
From: Reini U. <ru...@x-...> - 2002-10-02 17:00:15
|
Joby Walker schrieb: > Reini Urban wrote: >> Joby Walker schrieb: >> >>> 2) no admin account (ADMIN_GROUP): this would grant to specific users >>> WIKIAUTH_ADMIN privilages. With this enabled there is no admin >>> account, but certain users have administrative privilages. With this >>> modifications can be tracked by user. >> >> This will be a PagePermission feature, once groups are ready. > > > Any info on this? I will certainly help. Good. We just discussed the layout here, but I have no code yet, because of the UserAuth problems. See the mainlinglist and the phpwiki pages. We decided to put the groupmembers info into simple wikipages as * lines. PagePermission is just another numeric meta_data field "perm", similar to "hits" or "pref". Also a new field owner: "owner", with groups "owner.group"? or seperate? "userid" is the latest author. for upgrading the owner will be the original userid field. Then each action needs a central permission check in main(). For display, save/remove and various other executable plugins. I would move the basic read/write checks from main() to the WikiDB level. Then we have to enhance requiredAuthority ($action) to requiredAuthority ($action, $page), or make requiredAuthority ($action) a WikiDB method. For example to disallow the listing of private -r pages in PageList. or if an admin plugin may change other pages. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Joby W. <joby@u.washington.edu> - 2002-10-02 23:11:07
|
Reini Urban wrote:
We just discussed the layout here, but I have no code yet, because of
the UserAuth problems. See the mainlinglist and the phpwiki pages.
Ok found the discussion and am up to speed.
We decided to put the groupmembers info into simple wikipages as * lines.
Hmmm... I would have gone for DB fields, but then I wasn't paying
attention... See below.
PagePermission is just another numeric meta_data field "perm", similar
to "hits" or "pref".
'r' = view
'w' = edit
'x' = ? admin rights ?
Also a new field owner: "owner", with groups "owner.group"? or seperate?
"userid" is the latest author.
for upgrading the owner will be the original userid field.
I would store in seperate "owner" and "group" meta fields, if not in
fields on the page_tbl table (faster queries). See below.
Then each action needs a central permission check in main().
For display, save/remove and various other executable plugins.
I would move the basic read/write checks from main() to the WikiDB level.
Then we have to enhance requiredAuthority ($action) to
requiredAuthority ($action, $page),
ok
or make requiredAuthority ($action) a WikiDB method.
For example to disallow the listing of private -r pages in PageList.
or if an admin plugin may change other pages.
Yikes! That's a lot of parsing for an 'a-r g+r' page that isn't owned by
the user. It would be a lot easier if group membership was stored in
the DB:
1)
"SELECT groupname FROM $user_group_tbl WHERE username=$username"
vs.
2)
// Note: functions are just for demo of what is nec. not an actual
// proposal
// get all the groups
$groups = getGroups();
$membership = array();
foreach($groups as $x){
// grab/parse group page looking for username
if(userInGroup($x, $username)){
$membership[] = $x;
}
}
In #1 there is one DB call and in #2 there will be 1+N DB calls (where N
is the number of groups). #2 is not going to scale up very well.
jbw
** Sorry again Reini...ment to send to whole list. I am used to just
Replying (not Reply-Alling) to lists **
|
|
From: Jeff D. <da...@da...> - 2002-10-05 02:46:08
|
My random comments... > Then each action needs a central permission check in main(). > For display, save/remove and various other executable plugins. > I would move the basic read/write checks from main() to the WikiDB > level. I'd leave it where it is, I think. It's the WikiDB's job to tell you the owner and protection mode (which it already does via meta-data). > Then we have to enhance requiredAuthority ($action) to > requiredAuthority ($action, $page), That seems fine. Except that requiredAuthority is a method of WikiRequest which already knows the $page, I think.... > 1) > "SELECT groupname FROM $user_group_tbl WHERE username=$username" > > vs. > > 2) (Group data in wiki pages) > In #1 there is one DB call and in #2 there will be 1+N DB calls (where N > > is the number of groups). #2 is not going to scale up very well. #1 requires an SQL backend as well as modifications to WikiDB (or a separate interface to the SQL db). There are speed issues with #2, but I don't think they're as bad as Joby says. Each page belongs to only one group, so for a given access we only have to check for membership in a single group --- not all groups... |
|
From: Joby W. <joby@u.washington.edu> - 2002-10-07 16:30:45
|
Jeff Dairiki wrote: >>1) >>"SELECT groupname FROM $user_group_tbl WHERE username=$username" >> >>vs. >> >>2) > > (Group data in wiki pages) > > >>In #1 there is one DB call and in #2 there will be 1+N DB calls (where N >> >>is the number of groups). #2 is not going to scale up very well. > > > #1 requires an SQL backend as well as modifications to WikiDB (or > a separate interface to the SQL db). Correct this solution will be harder to impliment. Not only does it require the backend support for each DB, but there is also the need for administrative plugins (plugins that check permissions) to add people to groups and to create groups. > > There are speed issues with #2, but I don't think they're as bad > as Joby says. Each page belongs to only one group, so > for a given access we only have to check for membership in a single > group --- not all groups... You're correct Jeff. For each page that is a-r, g+r, and not owned by the viewer only one group page would need to be accessed (unless we allow groups to belong to groups, **shudder**). So most pages will not require the rendering of a group page. The 1+N problem comes into fruition in situations where we want to get all of the groups to which the user belongs. The example Reini put forward was if we want to limit searches to only pages the user can view. After some thought there is no reason we can't abstract this and do both (with a config option and WikiGroup::getGroup) with a group object that would be called within WikiRequest or WikiUser. Since the #2 is going to be FAR easier to impliment and #1 requires some other work done, #2 will be the proto-type. I'll have a mock up in the near future. jbw |
|
From: Joby W. <joby@u.washington.edu> - 2002-10-02 16:15:02
|
Reini Urban wrote: > Joby Walker schrieb: > >> 1) a new login method (currently PUBCOOKIE_LOGIN): this will allow >> end user to use the University of Washington's Pubcookie system. >> When using Pubcookie the end user accesses a web site he is forced to >> authenticate at a central site, and the central login site then >> guarantees the authentication to the web site. Thus the end user's >> password is never available to the web site, and allowing a unified >> login structure for an organization. The only check is that >> $HTTP_SERVER_VARS['REMOTE_USER'] is guaranteed to be set and correct. > > > > I'm against adding this to the default HEAD branch of phpwiki. > I know that some sites do cookie auth, and even we do it in our > internal backoffice, but this is totally insecure. > Why is this more insecure than other methods? Pubcookie follows the kerberos model for single login access, and was the first model accepted by the Internet2's WebISO project: http://middleware.internet2.edu/webiso/ Many universities use a similar login system, and they will become much more common in the near future. More info on UW's Pubcookie: http://www.washington.edu/pubcookie/ If you are worried about stolen cookies, why are we using PHPSessions? They are only 128bit numbers. > But I already added beta support for ALLOW_HTTP_AUTH_LOGIN which > accepts already logged in users. > Unfortunately, ALLOW_HTTP_AUTH_LOGIN is not useful for my purposes. With pubcookie there is no password to go with the $HTTP_SERVER_VARS['REMOTE_USER'] (because only the login server is trusted with passwords), thus as structured a login would be impossible. And you can't allow a REMOTE_USER login with out a password, because then there would be no protection against a user changing to a different account (since none of them have passwords) -- thus the necessity of the WikiUserID == REMOTE_USER (which breaks the administrative account). jbw P.S. Sorry Reini, ment to sent to the whole list... |
|
From: Reini U. <ru...@x-...> - 2002-10-02 17:46:37
|
Joby Walker schrieb: > Reini Urban wrote: >> Joby Walker schrieb: >> >>> 1) a new login method (currently PUBCOOKIE_LOGIN): this will allow >>> end user to use the University of Washington's Pubcookie system. >>> When using Pubcookie the end user accesses a web site he is forced to >>> authenticate at a central site, and the central login site then >>> guarantees the authentication to the web site. Thus the end user's >>> password is never available to the web site, and allowing a unified >>> login structure for an organization. The only check is that >>> $HTTP_SERVER_VARS['REMOTE_USER'] is guaranteed to be set and correct. >> >> I'm against adding this to the default HEAD branch of phpwiki. >> I know that some sites do cookie auth, and even we do it in our >> internal backoffice, but this is totally insecure. > > Why is this more insecure than other methods? Oops. I mixed that up with our local php cookie login systems, which I had to fix. pubcookie seems to be a good thing. So why not? Seems not too hard to support in phpwiki, but requires lots of changes in apache. I'll have a look. http://www.washington.edu/computing/pubcookie/uwash-mod-1.77.html How do you detect this pubcookie session with PHP besides $_ENV['REMOTE_USER'] and $_COOKIE[PUBCOOKIE_NetID]? http://www.washington.edu/computing/web/publishing/uwnetid.html REFERER? Maybe any SSL var? > Pubcookie follows the kerberos model for single login access, and was > the first model accepted by the Internet2's WebISO project: > > http://middleware.internet2.edu/webiso/ > > Many universities use a similar login system, and they will become much > more common in the near future. > > More info on UW's Pubcookie: > > http://www.washington.edu/pubcookie/ > > If you are worried about stolen cookies, why are we using PHPSessions? > They are only 128bit numbers. > >> But I already added beta support for ALLOW_HTTP_AUTH_LOGIN which >> accepts already logged in users. > > Unfortunately, ALLOW_HTTP_AUTH_LOGIN is not useful for my purposes. With > pubcookie there is no password to go with the > $HTTP_SERVER_VARS['REMOTE_USER'] (because only the login server is > trusted with passwords), thus as structured a login would be impossible. > And you can't allow a REMOTE_USER login with out a password, because > then there would be no protection against a user changing to a different > account (since none of them have passwords) -- thus the necessity of the > WikiUserID == REMOTE_USER (which breaks the administrative account). -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Joby W. <joby@u.washington.edu> - 2002-10-02 20:41:34
|
Reini Urban wrote: > Joby Walker schrieb: > >> Reini Urban wrote: >> >>> Joby Walker schrieb: >>> >>>> 1) a new login method (currently PUBCOOKIE_LOGIN): this will allow >>>> end user to use the University of Washington's Pubcookie system. >>>> When using Pubcookie the end user accesses a web site he is forced >>>> to authenticate at a central site, and the central login site then >>>> guarantees the authentication to the web site. Thus the end user's >>>> password is never available to the web site, and allowing a unified >>>> login structure for an organization. The only check is that >>>> $HTTP_SERVER_VARS['REMOTE_USER'] is guaranteed to be set and correct. >>> > > Oops. I mixed that up with our local php cookie login systems, which I > had to fix. pubcookie seems to be a good thing. > So why not? No problem, I like a healthy skepticism of a method's security! > > Seems not too hard to support in phpwiki, but requires lots of changes > in apache. I'll have a look. > > http://www.washington.edu/computing/pubcookie/uwash-mod-1.77.html > > How do you detect this pubcookie session with PHP besides > $_ENV['REMOTE_USER'] and $_COOKIE[PUBCOOKIE_NetID]? > > http://www.washington.edu/computing/web/publishing/uwnetid.html > > REFERER? > Maybe any SSL var? > I agree that support is pretty easy to add, but I would not make it an detected login method. If this method is needed, there is a significant amount of backend work that needs to be completed that I don't think we should worry about autodetection -- If this method is desired the wiki owner should just say so. In addition, if phpwiki makes a "false positive" detection of pubcookie, a serious security breach could result. All we need is: index.php (or config_user.php/config_dist.php): #define('USE_PUBCOOKIE_AUTH', true); if(!defined('USE_PUBCOOKIE_AUTH')) define ('USE_PUBCOOKIE_AUTH', false); WikiUser.php: function _pwcheck... // right after the ADMIN_USER check if(USE_PUBCOOKIE_AUTH){ if($HTTP_SERVER_VARS['REMOTE_USER'] == $userid){ return WIKIAUTH_USER; } return false; } jbw |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X