[Wikitech-l] ? earlier versions of user access levels + permissions
Hello, A short question about user access levels and permissions. Does anyone happen to know, if it is possible to download not the current version of the list of user access levels and permissions, http://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=usergroups, but a version of this list at a selected time, e.g., 2007-03-25T08:30:00Z ? Many thanks in advance, Illes -- http://hal.elte.hu/fij ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ? earlier versions of user access levels + permissions
2010/3/25 Farkas, Illes : > Hello, > > A short question about user access levels and permissions. > > Does anyone happen to know, if it is possible to download not the current > version of the list of user access levels and permissions, > http://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=usergroups, > but > a version of this list at a selected time, e.g., 2007-03-25T08:30:00Z ? > No. You can probably reconstruct this list yourself using the current list and the user rights log, but MediaWiki itself doesn't have this functionality. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ? earlier versions of user access levels + permissions
> > --- From: Farkas, Illes --- > > http://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=usergroups > a version of this list at a selected time, e.g., 2007-03-25T08:30:00Z ? > --- From: Roan Kattouw --- No. You can probably reconstruct this list yourself using the current > list and the user rights log, but MediaWiki itself doesn't have this > functionality. > Do you mean that the changes to the list of access levels are available? The current version of the list is at the above API address. (I do not mean the access levels of the actual users) Thanks again, Illes ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ? earlier versions of user access levels + permissions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 3/25/2010 2:45 AM, Farkas, Illes wrote: > > Do you mean that the changes to the list of access levels are available? The > current version of the list is at the above API address. (I do not mean the > access levels of the actual users) > > Thanks again, > Illes If you're referring to what rights a group is assigned, then no, there isn't a historical record. The only way, afaik, is possibly digging through the wikitech admin log and bugzilla and trying to piece it together. - -Q -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLqxm0AAoJEL+AqFCTAyc2tS0H/3uFyWGFLZ5gUeRp2jtPFyyY sAmbWZBuEmH73g2+Aa/sgUYa1R12NWR9X051SdK7ZQDd8WORzoNvHRWvUbqiBvKX yB6O1aUu/C8/FMYXi6kiME2Jq/WFkv2f/xWxJpY6JoK6Sd7throfdCO839NfuMN5 FxwQYc8rz/cx9m9+jZjWgf77GjvVqhDqHnjypQoFFFdjjMrXgHOamqprgXlyG8Rt sQmxbvX6cl04P3/zbNtnB9ChDDjl3oHr+MqgGmdMduaUgPCxMb1+cCAZ6ytkzlXz Xpa2px+PW+xJByaKENGfXSn41Zg8rOFyxuvnsqo8h0FiR4356iY90l+ftJgwsi4= =uGrx -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ExternalAuth design
On Thu, Mar 25, 2010 at 12:27 AM, Ryan Lane wrote: > I'd like to discuss the proposed change to the authentication plugin > system (http://www.mediawiki.org/wiki/ExternalAuth). As proposed, I > don't see how I'll be able to keep most of the functionality in the > LDAP extension. It isn't a change, it's an addition. AuthPlugin will be kept indefinitely, certainly at least until all users in trunk are obsoleted by equivalent ExtAuth plugins (which may well be never). > I don't disagree that policy and implementation shouldn't be mixed, > but core shouldn't be making all policy decisions. For instance, there > is an option in the LDAP extension ($wgLDAPDisableAutoCreate) that > disables auto-creation, but still allows auto-authentication. > Essentially, it says, if the user exists in LDAP, but not in the local > directory, don't automatically create the local account. Some > administrators want to create accounts for users in the wiki locally, > even though they already have accounts in LDAP. First off, if this is desirable for LDAP, it's desirable for other auth systems too. Therefore, in ExtAuth, this feature would be added to the core code, *not* individual extensions, so that it could be used by *all* backends. The LDAP-specific stuff should only deal with stuff that is *really* specific to LDAP, like connecting to the LDAP server and mapping MediaWiki auth info to however LDAP stores things. Second, I'm not sure what you mean by "disables auto-creation, but still allows auto-authentication". The user must be authenticated as *some* user that exists in the MediaWiki database, no? How does auto-authentication work in this case? This might be the same as $wgAutocreatePolicy. The default is 'login', which autocreates accounts if a user logs in, their auth information doesn't match any local account, and it does match an external account. You can also set it to 'never', which never autocreates local accounts (so they have to be manually linked, which doesn't work yet); and 'view', which will try to autocreate from cookies or such if supported by the backend. > Will getGroups() assign users to whatever groups the backend returns? > The way I'm currently doing this is adding users to groups if they are > available groups in the wiki (if they've been defined in > $wgGroupPermissions). I don't use auto-promote at all. You mean, you just take the group name strings returned by LDAP and assign them to the user as MediaWiki groups? That's an interesting idea, provided there are no conflicts. It would be a lot simpler than using auto-promote. However, it could cause problems if group names were weird, like with spaces or something, since a lot of code probably assumes they look like typical MediaWiki group names. Still, I think this is a better approach. Currently this isn't actually implemented at all in ExtAuth, so it could be changed to the method you describe easily enough. > The LDAP plugin can add users to the LDAP database. Is this also going > to support that? That's a possible feature, although I don't think it's in any of my design documents. For many backends it would be impractical, but it would make sense for LDAP. I mostly designed this to allow authentication on my site's wiki from vBulletin, another web app, so the design is probably skewed toward that, but I'm pretty sure it's flexible enough that it could be adjusted to support LDAP well. > The LDAP plugin allows a user to authenticate with one username, but > have the username created be something else. This is absolutely a > must-have for auto-authentication, where a user might authenticate > with Kerberos or an SSL certificate. If a user authenticates with an > SSL certificate, their username may be something insane, like a > numeric ID with special characters. The LDAP plugin would search the > LDAP directory for another attribute that should be used for the > username. Notice that you don't necessarily want to treat the > auto-auth name as an ID either. You may pull both a new username, and > a unique ID from the LDAP server; this is an especially likely > scenario in a large organization, where a user may have a global > unique ID, but in some places they may have a locally unique ID (think > mergers). This is part of the design for ExternalAuth, although it hasn't yet been implemented. It's necessary for any backend that doesn't have username restrictions as rigid as MediaWiki, or that uses incomprehensible usernames. Even if you're just authenticating to an external MediaWiki, it's necessary to resolve conflicts. (In particular, this is necessary for vBulletin, since that permits characters like / in names, but it's not so essential, since most names don't have them -- which is why it's not implemented yet.) > There are situations where newFromId( $id ) and getId() won't work. > Active Directory (AD) is a case where it is unlikely to work for most > people. By default AD does not allow anonymous searches. There
Re: [Wikitech-l] ExternalAuth design
>> I'd like to discuss the proposed change to the authentication plugin >> system (http://www.mediawiki.org/wiki/ExternalAuth). As proposed, I >> don't see how I'll be able to keep most of the functionality in the >> LDAP extension. > > It isn't a change, it's an addition. AuthPlugin will be kept > indefinitely, certainly at least until all users in trunk are > obsoleted by equivalent ExtAuth plugins (which may well be never). > Ah. That's good. I have a good feeling I'll be moving to the new system as I definitely like some of the ideas in it so far. I especially like that the extension will be passed the exact username string typed by the user. I have some open bugs regarding that. >> I don't disagree that policy and implementation shouldn't be mixed, >> but core shouldn't be making all policy decisions. For instance, there >> is an option in the LDAP extension ($wgLDAPDisableAutoCreate) that >> disables auto-creation, but still allows auto-authentication. >> Essentially, it says, if the user exists in LDAP, but not in the local >> directory, don't automatically create the local account. Some >> administrators want to create accounts for users in the wiki locally, >> even though they already have accounts in LDAP. > > First off, if this is desirable for LDAP, it's desirable for other > auth systems too. Therefore, in ExtAuth, this feature would be added > to the core code, *not* individual extensions, so that it could be > used by *all* backends. The LDAP-specific stuff should only deal with > stuff that is *really* specific to LDAP, like connecting to the LDAP > server and mapping MediaWiki auth info to however LDAP stores things. > That makes sense. My only concern is that this will require extension developers to dive into core to add features they'd normally add to their own extension. This isn't necessarily a bad thing, as their changes could benefit everyone. > Second, I'm not sure what you mean by "disables auto-creation, but > still allows auto-authentication". The user must be authenticated as > *some* user that exists in the MediaWiki database, no? How does > auto-authentication work in this case? > > This might be the same as $wgAutocreatePolicy. The default is > 'login', which autocreates accounts if a user logs in, their auth > information doesn't match any local account, and it does match an > external account. You can also set it to 'never', which never > autocreates local accounts (so they have to be manually linked, which > doesn't work yet); and 'view', which will try to autocreate from > cookies or such if supported by the backend. > Setting it to 'never' would likely fit this situation; I believe this is the correct use case (I've never used this functionality personally). > You mean, you just take the group name strings returned by LDAP and > assign them to the user as MediaWiki groups? That's an interesting > idea, provided there are no conflicts. It would be a lot simpler than > using auto-promote. However, it could cause problems if group names > were weird, like with spaces or something, since a lot of code > probably assumes they look like typical MediaWiki group names. > > Still, I think this is a better approach. Currently this isn't > actually implemented at all in ExtAuth, so it could be changed to the > method you describe easily enough. > I add users into the groups; I don't add groups to users. I do this by: 1. Getting a list of all groups ($user->getAllGroups()), and a list of groups the user is in ($user->getEffectiveGroups()) 2. I iterate through the list of all groups and: 2a. Add the user into the wiki group if they are in the external group 2b. Remove the user from the wiki group if they are in the wiki group, but no longer in the external group Effectively, I'm synchronizing the groups every login. This means the admin must choose which groups they want to synchronize by creating them in LocalSettings.php using $wgGroupPermissions, by adding permissions to the group. I do have functionality to add all groups to $wgGroupPermissions (via $wgLDAPGroupsPrevail), so that other extensions can use the groups, but that code is *really* expensive, as sometimes users are in hundreds of groups; I'm unfortunately not exaggerating about the hundreds of groups, I've done a support request where someone had users that had 500+ groups. > > The LDAP plugin can add users to the LDAP database. Is this > also going > > to support that? > > That's a possible feature, although I don't think it's in any of my > design documents. For many backends it would be impractical, but it > would make sense for LDAP. I mostly designed this to allow > authentication on my site's wiki from vBulletin, another web app, so > the design is probably skewed toward that, but I'm pretty sure it's > flexible enough that it could be adjusted to support LDAP well. > Some extensions use this to manage an external database that all their applications use. It is a fairly esoteric
Re: [Wikitech-l] ExternalAuth design
On Thu, Mar 25, 2010 at 11:36 AM, Lane, Ryan wrote: > Actually, no. LDAP usernames are not assumed to be unique, or stable. > Generally, usernames are based on some combination of a person's name. > People's names can change for various reasons (marriage, legal name change, > etc.). When a person's name changes, their username changes with it. LDAP > entries are assumed to have some unique identifier that is often different > than the username. In the Posix schema, this is uidNumber. In Active > Directory, it is often the Security Identifier (SID), but may also be the > userAlternativeName attribute, which is often the case in smart card > infrastructures. > > In the Posix schema, this is guaranteed to be an integer, but in Active > Directory, it will most likely be a string, and can be fairly long. > Wouldn't varchar(255) generally be enough to handle the SID from AD? IIRC (feel free to call me out badly if I'm wrong), Microsoft uses their standard GUID format, so it'd be something along the lines of "C8535E2E-148D-494d-8E9A-71FC46649B5E?" -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ExternalAuth design
> Wouldn't varchar(255) generally be enough to handle the SID from AD? > IIRC (feel free to call me out badly if I'm wrong), Microsoft > uses their > standard GUID format, so it'd be something along the lines of > "C8535E2E-148D-494d-8E9A-71FC46649B5E?" > Yeah, I seriously doubt any system is going to have a unique identifier longer than 255 characters. I know after this is implemented I'll find some crazy organization doing this though ;) (like the one that had a user with over 500 groups - crazy). Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ? earlier versions of user access levels + permissions
Q wrote: > On 3/25/2010 2:45 AM, Farkas, Illes wrote: > >> Do you mean that the changes to the list of access levels are available? The >> current version of the list is at the above API address. (I do not mean the >> access levels of the actual users) > >> Thanks again, >> Illes > > If you're referring to what rights a group is assigned, then no, there > isn't a historical record. The only way, afaik, is possibly digging > through the wikitech admin log and bugzilla and trying to piece it together. > > -Q Only really old user rights were done by developers. Any recent group changes would be viewable in: http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=rights or -for sysop demotions- http://meta.wikimedia.org/w/index.php?title=Special%3ALog&type=rights ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Common.css not working
Jean-Marc van Leerdam wrote: > Regardless of whether you succeed in hiding the 'view source' tab, how > will you counter URL manipulation by the user? > > AFAIK anyone can change the URL to > > ...index.php?title=Pagename&action=edit > > and then get presented with the 'view source' results (or the edit > window for that matter if the user/anon has edit rights). > > Or are you only concerned in the aestethics of the page rendering? The [view source] tab appears only when you don't have permission to edit it, so going to the direct url won't allow you to modify it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ? earlier versions of user access levels + permissions
On Thu, Mar 25, 2010 at 12:24 PM, Platonides wrote: > Q wrote: >> On 3/25/2010 2:45 AM, Farkas, Illes wrote: >> >>> Do you mean that the changes to the list of access levels are available? The >>> current version of the list is at the above API address. (I do not mean the >>> access levels of the actual users) >> >>> Thanks again, >>> Illes >> >> If you're referring to what rights a group is assigned, then no, there >> isn't a historical record. The only way, afaik, is possibly digging >> through the wikitech admin log and bugzilla and trying to piece it together. >> >> -Q > > Only really old user rights were done by developers. > > Any recent group changes would be viewable in: > http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=rights > or -for sysop demotions- > http://meta.wikimedia.org/w/index.php?title=Special%3ALog&type=rights > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > He's not asking about rights changes for user accounts. He was wanting to look at the historical values of $wgGroupPermissions. Like was said earlier in the thread, the only way to find that is to do some digging through Bugzilla and who knows where else to find discussions relating to changes in the setup of user rights. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ? earlier versions of user access levels + permissions
Q gmail.com> writes: > If you're referring to what rights a group is assigned, then no, there > isn't a historical record. The only way, afaik, is possibly digging > through the wikitech admin log and bugzilla and trying to piece it together. The default user group rights are set in includes/DefaultSettings.php (or the relevant extensions) and their history can be recreated from SVN. Most default associations were never overridden (though those are the less interesting ones, I suppose). Important changes can usually be found in Bugzilla, under the Wikimedia/Site requests component. You could also try to check the page history of http://en.wikipedia.org/wiki/Wikipedia:User_access_levels . ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ? earlier versions of user access levels + permissions
Chad wrote: > He's not asking about rights changes for user accounts. He was wanting > to look at the historical values of $wgGroupPermissions. > > Like was said earlier in the thread, the only way to find that is to do some > digging through Bugzilla and who knows where else to find discussions > relating to changes in the setup of user rights. > > -Chad Oh, sorry. I would look at current groups different than the default and how the default changed over time. But not all current rights existed at 2007. And the features also changed. For example everybody had what is now deletedhistory for some time, then it was made a new permission and set to false (r12241). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Common.css not working
Hi everyone I think i found the answer. Its an extension called GroupPermissionsManager http://www.mediawiki.org/wiki/Extension:GroupPermissionsManager. Thanks On Fri, Mar 26, 2010 at 5:21 AM, Platonides wrote: > Jean-Marc van Leerdam wrote: > > Regardless of whether you succeed in hiding the 'view source' tab, how > > will you counter URL manipulation by the user? > > > > AFAIK anyone can change the URL to > > > > ...index.php?title=Pagename&action=edit > > > > and then get presented with the 'view source' results (or the edit > > window for that matter if the user/anon has edit rights). > > > > Or are you only concerned in the aestethics of the page rendering? > > The [view source] tab appears only when you don't have permission to > edit it, so going to the direct url won't allow you to modify it. > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ExternalAuth design
On Thu, Mar 25, 2010 at 11:36 AM, Lane, Ryan wrote: > That makes sense. My only concern is that this will require extension > developers to dive into core to add features they'd normally add to their > own extension. This isn't necessarily a bad thing, as their changes could > benefit everyone. My goal is to not have this done in extensions at all. Everything should be in core, ideally. This encourages people to write clean, reasonable code -- current AuthPlugins duplicate code massively, with all the problems that entails. Each one supports a different set of functionality in different ways. Of course, the interface should also be stable and suitable for extensions, but any ExtAuth plugin in SVN should be in core, not extensions, IMO. > I add users into the groups; I don't add groups to users. I do this by: > > 1. Getting a list of all groups ($user->getAllGroups()), and a list of > groups the user is in ($user->getEffectiveGroups()) > 2. I iterate through the list of all groups and: > 2a. Add the user into the wiki group if they are in the external group > 2b. Remove the user from the wiki group if they are in the wiki group, but > no longer in the external group > > Effectively, I'm synchronizing the groups every login. I see. This sounds like it would have a couple of notable issues: * Special:UserRights would be pretty confusing. Additions and removals would seem to work, but only until the user next logged in. * Group changes would only take effect on login. Users might only log in once a month. I was thinking that the groups should be implicit, like autoconfirmed, not explicit. This would require a query to the backend on every permissions check, however, for linked accounts. Some type of caching could be optionally used -- maybe just storing the list of groups in the User object and relying on the fact that that's cached. > Well, the proposal mentions allowing the user to choose their own username. > That is fine for some extensions (OpenID does this, for instance), and it > may even be useful for the LDAP plugin, but I'd like to ensure the plugin > can choose the name without giving the user an option. What are the use-cases for this? What sorts of names would you want to auto-assign? It sounds like this would best be done by exposing some kind of hook, if it's meant to be for stuff as narrow as semi-anonymous users. E.g., just have a hook somewhere in account autocreation that gets passed the User and ExternalUser objects, and let it choose a name if it likes. > It would be *really* nice if this worked for both regular, and > auto-authentication, as right now it only works for auto-authentication; I > use this for a semi-anonymous user feature, but it only works for auto-auth: > > http://ryandlane.com/blog/2009/06/18/semi-anonymous-users-in-mediawiki-using > -the-ldap-authentication-extension/ I'm not sure what the difference is between regular and auto-authentication. > Actually, no. LDAP usernames are not assumed to be unique, or stable. > Generally, usernames are based on some combination of a person's name. > People's names can change for various reasons (marriage, legal name change, > etc.). When a person's name changes, their username changes with it. LDAP > entries are assumed to have some unique identifier that is often different > than the username. In the Posix schema, this is uidNumber. In Active > Directory, it is often the Security Identifier (SID), but may also be the > userAlternativeName attribute, which is often the case in smart card > infrastructures. > > In the Posix schema, this is guaranteed to be an integer, but in Active > Directory, it will most likely be a string, and can be fairly long. Okay, now I'm confused. So you're saying that there is no stable, unique identifier that can be used for querying information about a user? The only identifier you can use is the username, and that's unstable? That seems decidedly inconvenient. How is any external system supposed to integrate with the authentication system if there are no stable identifiers? > The LDAP plugin detects the external account was renamed the following way: > > On account creation, the plugin records the external ID. On authentication, > the plugin queries LDAP, and gets the username back. If the username is > different than the local account, the plugin renames the account, or blocks > login, which should inform the user to contact the site admin. If the new > username is already taken, the plugin blocks login, which should inform the > user to contact the site admin. > > Allowing the user to choose a new name in this situation wouldn't really > make sense, as the extension is assuming the external username matches the > local one. Keeping the name the same is also really problematic for most > organizations using LDAP, as usernames may be re-used. ExtAuth takes the philosophy that the wiki name may be totally disconnected from the external name. It would certainly make sense to
Re: [Wikitech-l] ExternalAuth design
> > Effectively, I'm synchronizing the groups every login. > > I see. This sounds like it would have a couple of notable issues: > > * Special:UserRights would be pretty confusing. Additions and > removals would seem to work, but only until the user next logged in. This wouldn't be an issue if it updated the external database when adding users. Some backends may not support this... This may be one spot where policy should be decided by the backend. > * Group changes would only take effect on login. Users might only log > in once a month. > This is actually fairly normal for most applications. Operating systems work exactly like this. Web SSO systems are also like this. In most web SSO systems, admins have the ability to invalidate a session when they change something for a user. Maybe an interface could be added to invalidate user sessions? It might also be possible to force a group check on sessions older than a specified time. > I was thinking that the groups should be implicit, like autoconfirmed, > not explicit. This would require a query to the backend on every > permissions check, however, for linked accounts. Some type of caching > could be optionally used -- maybe just storing the list of groups in > the User object and relying on the fact that that's cached. > This could work too, but it could be really expensive depending on the length of the cache. Can you explain how this implementation might be configured? I'm not terribly familiar with the auto-promote stuff. > What are the use-cases for this? What sorts of names would you want > to auto-assign? It sounds like this would best be done by exposing > some kind of hook, if it's meant to be for stuff as narrow as > semi-anonymous users. E.g., just have a hook somewhere in account > autocreation that gets passed the User and ExternalUser objects, and > let it choose a name if it likes. > It isn't as narrow as that. The LDAP extension may use it for any form of auto-auth, like Kerberos or SSL authentication, where the username provided is something odd like "ryan.l...@example.org", or "Example_Organization__RYAN.LANE.12345". In those cases, the MediaWiki admin probably wants to use an attribute like sAMAccountName (for AD), or uid (which is actually the username, not the uid, in the Posix schema). I do actually handle this via a hook in my extension, but that hook passes the user's LDAP object to pull attributes from. See this smartcard configuration as an example: http://www.mediawiki.org/wiki/Extension:LDAP_Authentication/Smartcard_Config uration_Examples#Basic_LDAP_extension_configuration > I'm not sure what the difference is between regular and > auto-authentication. > Auto-authentication occurs without user interaction, generally because something else has already done the authentication (like the web server); it is currently provided via the UserLoadAfterLoadFromSession hook. Regular authentication is when the user logs in through SpecialUserlogin. > Okay, now I'm confused. So you're saying that there is no stable, > unique identifier that can be used for querying information about a > user? The only identifier you can use is the username, and that's > unstable? That seems decidedly inconvenient. How is any external > system supposed to integrate with the authentication system if there > are no stable identifiers? > No. I'm saying there is a stable identifier that is generally not used for authentication. A username is a user friendly identifier that is unique, but not stable. Generally, you integrate with the user friendly identifier, and keep track of the stable identifier, in case the user friendly one changes. > ExtAuth takes the philosophy that the wiki name may be totally > disconnected from the external name. It would certainly make sense to > allow admins to require them to always be the same, though -- as long > as the backend doesn't have usernames that MediaWiki doesn't allow. > This would work well as a configuration option. Most enterprise wiki admins want to ensure users can't pick their own usernames. > I don't know. If it's necessary, it can always be merged to core, > IMO. That's the nice thing about developing in core. ;) > Heh. Good point. I think it will likely need to be merged. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Common.css not working
Hi, On 25 March 2010 17:21, Platonides wrote: > Jean-Marc van Leerdam wrote: >> Regardless of whether you succeed in hiding the 'view source' tab, how >> will you counter URL manipulation by the user? >> >> AFAIK anyone can change the URL to >> >> ...index.php?title=Pagename&action=edit >> >> and then get presented with the 'view source' results (or the edit >> window for that matter if the user/anon has edit rights). >> >> Or are you only concerned in the aestethics of the page rendering? > > The [view source] tab appears only when you don't have permission to > edit it, so going to the direct url won't allow you to modify it. > Yes, I know that, what I wanted to add is that suppressing the 'view source' tab as a means to hide the Wiki source from viewers is insufficient. -- Regards, Jean-Marc -- . ___ . @@ // \\ "De Chelonian Mobile" . (_,\/ \_/ \ TortoiseSVN . \ \_/_\_/>The coolest Interface to (Sub)Version Control . /_/ \_\ http://tortoisesvn.net ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
