Dan,
I'm trying to implement this so I don't have to keep manually make the
change for every update. Not 100% sure how I will eventually
implement this so this would be good until I figure it out.
Not sure I am doing this right though.
It appears that the config.php file is looked for from a config
directory off the main site (same level as the boltwire directory).
So I created the directory called config and in that directory I put
the file config.php
In that file, I have the following...
- - - - - - - - - - - - - - - - - - - -
<?php
$BOLTtoolmap['x']['login'] = 'mylogin';
$BOLTtoolmap['x']['register'] = 'myregister';
function BOLTXmylogin($value, $field) {
## HERE'S THE COMMAND THAT TAKES A MEMBER AND PASSWORD FORM VALUE AND
AUTHENTICATES AGAINST THE USE
R PROFILE DATA. CAN HANDLE ENCRYPTED OR UNENCRYPTED VALUES, AND
AUTOMATIC LOGINS. AFTER AUTHENTICAT
ED ALL GROUP MEMBERSHIPS ARE DETERMINED AND PROPER PERMISSIONS
ASSIGNED
global $pageLink, $BOLTarray, $msg, $BOLTid, $BOLTmember,
$BOLTfieldKey;
$BOLTloginPages = BOLTconfig('BOLTloginPages', 'login');
$BOLTcrypt = BOLTconfig('BOLTcrypt');
if ($BOLTid != '') BOLTabort('login_problem');
if (strpos($BOLTarray['member'], '@')) {
$page = BOLTFsearch(Array('data'=>"email=$BOLTarray
[member]", 'group'=>$BOLTloginPa
ges, 'count'=>1, 'join'=>'', 'fmt'=>'{+p}'), 'COMMAND', false);
$member = substr($page, strlen($BOLTloginPages) + 1);
}
else {
$member = BOLTfilter(BOLTutf2url($BOLTarray
['member']), 'csv');
$page = BOLTpageshortcuts("$BOLTloginPages.$member");
}
$id = substr($page, strlen($BOLTloginPages) + 1);
if (isset($BOLTarray['name'])) $member = BOLTfilter($BOLTarray
['name'], 'csv');
else {
$name = BOLTvars("$page:member", '', false);
if ($name != '') $member = $name;
}
$BOLTarray['member'] = $member;
$pass1 = BOLTvars("$page:password", '', false);
$pass2 = $BOLTarray['password'];
if ((($pass1 == $pass2 || $pass1 == BOLTXcrypttype($pass2,
$BOLTcrypt)) && ($pass1 != ''))
|| ($value == 'auto' )){
session_start();
$_SESSION[$BOLTfieldKey]['ID']['id'] = $id;
$_SESSION[$BOLTfieldKey]['ID']['member'] = $member;
session_write_close();
$BOLTid = $id;
$BOLTmember = $member;
$memberships = BOLTFmemberships(Array
('output'=>'true'));
$msg['login_success'] = "~$member";
setcookie('cache', $memberships, time() + 86000);
}
else BOLTabort('login_fail');
return $value;
}
function BOLTXmyregister($value, $field) {
## JUST A SHORTCUT FUNCTION FOR USER REGISTRATION. DOES SEVERAL BASIC
CHECKS OF USER INPUT. IF ALL
LOOKS OK, CREATES USER PROFILE AND LOGS THEM IN. TAKES A CSV LIST OF
FIELDS AND SAVES THEM AS DATA
VALUES TO USER PROFILE (OR SPECIFIED IN REGISTERPAGE). DOES NOT SEEM
TO ASSIGN GROUP MEMBERSHIPS.
global $BOLTarray, $BOLTid, $msg, $target;
$BOLTloginPages = BOLTconfig('BOLTloginPages', 'login');
$BOLTcrypt = BOLTconfig('BOLTcrypt');
if (!isset($BOLTarray['member'])) BOLTabort
('register_no_member');
if ($BOLTarray['member'] == "") BOLTabort
('register_member_blank');
$logingroup = $BOLTloginPages;
$page = BOLTpageshortcuts("$logingroup.$BOLTarray[member]");
if (! BOLTfilter($page, 'page')) BOLTabort
('register_invalid_name');
if (BOLTexists($page)) BOLTabort('register_member_exists');
if (isset($BOLTarray['email'])) { // && $BOLTarray
['checkemail'] !== 'false'
if (preg_match('/^...@.+\..+$/', $BOLTarray['email'])
== 0) BOLTabort('register_ema
il_fails');
$checkemail = BOLTFsearch(Array('data'=>"email=
$BOLTarray[email]", 'group'=>$BOLTlo
ginPages), 'COMMAND', false);
if ($checkemail != '') BOLTabort
('register_email_exists');
}
if (!BOLTauth($page, $BOLTid, 'write')) BOLTabort
('register_fail_auth');
if (!isset($BOLTarray['password'])) BOLTabort
('register_no_pass');
if ($BOLTarray['password'] == '') BOLTabort
('register_pass_blank');
$tempPass = $BOLTarray['password'];
if ($BOLTarray['loginfmt'] != "plaintext") $BOLTarray
['password'] = BOLTXcrypttype($BOLTarr
ay['password'], $BOLTcrypt);
if (isset($BOLTarray['registerpage'])) $page =
BOLTpageshortcuts($BOLTarray['registerpage']
);
$tempLink = $target;
$target = $page;
BOLTXsavedata(str_replace('password', '', $value),
'savedata');
BOLTsavedata(Array('password'=>$BOLTarray['password']),
$target, false);
$target = $tempLink;
$BOLTarray['password'] = $tempPass;
if (BOLTexists($target)) $msg['register_success'] = '';
else BOLTabort('register_fail');
return $value;
}
function BOLTXcrypttype($value, $field) {
## FUNCTION ENCODES A VALUE USING THE METHOD OF ENCRYPTIONG SET IN
SITE.CONFIG.
global $pageLink, $BOLTarray, $msg, $BOLTid, $BOLTmember,
$BOLTfieldKey;
$BOLTcrypt = BOLTconfig('BOLTcrypt');
$BOLTcryptType = BOLTconfig('BOLTcryptType');
if ($BOLTcryptType == "md5") {
$return = md5($value.$BOLTcrypt);
} else {
$return = crypt($value,$BOLTcrypt);
}
return $return;
}
?>
- - - - - - - - - - - - - - - - - - - -
It doesn't appear to be seeing the config.php file however. Am I
putting this in the correct place?
Perhaps I just need to name the functions as mylogin rather than
BOLTXmylogin etc... ?? Just tried that too.
On Sep 7, 11:42 am, The Editor <[email protected]> wrote:
> On Mon, Sep 7, 2009 at 1:46 PM, Kevin<[email protected]> wrote:
>
> > On Sep 7, 9:24 am, The Editor <[email protected]> wrote:
> >> Kevin, sorry for not getting back to you earlier on this. Let me share
> >> with you how I would recommend solving this problem.
>
> >> 1) Avoid any changes to the core functions. That means you will have
> >> to remake the change every time theres an upgrade. This should be a
> >> hard and fast rule--never change anything there. There's virtually
> >> always a way to work around what you want.
>
> >> 2) I'm not opposed to adding a new feature to the core, if you think
> >> there is merit in it. It's only a couple extra lines. Generally,
> >> though, I think something like this would do better as a plugin, as it
> >> is probably not a common need.
>
> > No problem with above... not sure how many people would need what I am
> > looking at.
>
> Agreed then.
>
>
>
> >> 3) I think the easiest solution would be to use toolmapping to create
> >> a custom function. You can do this with any function, command, or
> >> condition. In your config.php file try this:
>
> >> $BOLTtoolmap['x']['login'] = 'mylogin';
> >> $BOLTtoolmap['x']['register'] = 'myregister';
>
> >> This means map any calls to the login command (x) should go to
> >> function mylogin instead. Use f for function and c for condition.
>
> > Can toolmapping be used in a plugin? By that I mean, if I created a
> > plugin with replacement login and register functions could it have the
> > toolmapping to tell the system to override the current functions. Or
> > is there something else that can do that in a plugin?
>
> > I was wondering that when I was making the changes that I did.
>
> Certainly. You can put the toolmap line, and the replacement functions
> either in config.php or a plugin. Generally I develop in config.php,
> and then when I get the code to work, I just cut and paste the needed
> lines out and and into a plugin file.
>
> If you are curious, the routine that calls up the various config files
> and plugins is found in engine.php around line 202-216. You will
> notice (perhaps) that it not only loads config.php, but also the
> closest hierarchical config file, like config.forum.php, a skin.php
> file, and plugins. You can also enable plugins in config files
> (include_once) under whatever coding rules you like. For example, load
> this plugin if an admin, or if the day is tuesday or whatever. So you
> have pretty good flexibility. And while we're at it, remember you can
> even overwrite whole toolsets, sitewide or hierarchically. So lets say
> you wanted a very limited set of functions to be available in a forum
> hierarchy, you could write a forum.functions.php and it would get
> loaded instead of functions.php. All just fyi.
>
> >> Next copy the login and register commands from the commands.php script
> >> to your config file, and rename them mylogin, myregister. And make any
> >> changes to the code that you wish. In this case, changing crypt tomd5
> >> in all appropriate places.
>
> > I understand the part about pulling the login and register commands so
> > that I could make changes to them, but I don't get the config file
> > part. Which config file are you talking about?
>
> BoltWire always looks for and loads a file at field/config/config.php.
> Virtually anything can be configured here or in a plugin (or
> hierarchically as noted above). The settings in site.config or only
> limited configuration options. And they are always ignored when
> overwritten in a php file. So you could set any setting in site.config
> programmatically. IE, setting a skin based on user preferences or
> whatever. That is, based on any php conditions you wish. Ask if you
> want to now how.
>
>
>
> >> 4) You're finished! All your usual login features in BoltWire now get
> >> rerouted to your custom functions and you can do upgrades at any time
> >> you like, without losing functionality. Of course, if there was an
> >> improvement to the core login/register functions, your custom
> >> functions would not contain those improvements unless you updated them
> >> to be based on the newer code. For example, in the last release or two
> >> I added a small bit of new functionality to how the register function
> >> handles emails. Of course, those are usually noted in the changelog...
>
> >> I would probably not use commands code/encode/decode as they are used
> >> by some other plugins, and might have better uses down the road. But
> >> if your system is working, that's what counts. I do see you are
> >> catching on quick to how BoltWire works.
>
> >> --------------------------------
>
> >> On a related note, DrunkenMonk gave a nice snippet of code you could
> >> probably use to get a more universal login. I think that would be a
> >> nice feature. To get an outside function to save data to a page in
> >> BoltWire (such as a login page), you might want to look at the
> >> savedata functon in engine.php. Remember they are all alphabetized.
> >> You would have to hardcode a few variables/paths, and work around the
> >> few BoltWire functions in it (like exists, loadpage and savepage, but
> >> none of these should present too much trouble. So you could probably
> >> salvage some of the code to make a quick external script.
>
> > I didn't understand his post at the time, but am getting there now.
> > Learning curve.
>
> > Treading into custom zone here I think...
>
> > In one project that I am just starting, the need to user data in the
> > wiki is really not needed. All that is really needed is the ability
> > to validate who a user is by MySQL call to a common database.
>
> > Rather than creating login.user files, using your method mentioned
> > above it appears that I could replace the functions dealing with users
> > for login, register, exists etc...
>
> > Am I going to run into problems doing this where there are no
> > login.user files?
>
> Technically, no. I've been meaning to setup a msql plugin for
> awhile--and perhaps a plugin to do pagestores in a database. As well
> as data. I think it would be cool, and might be faster in some
> respects. I'd also like to do an ldap authentication plugin. BoltWire
> was designed early on with that kind of extensibility in mind.
> Certainly no problems to using alternate login/register functions.
>
> However, you might want to create profile pages just the same, to
> store at least some profile data, even if not used for login info,
> because I suspect you might have some problems possibly with
> shortcuts. For example, I use [[~someid]] all the time to create
> quick links to the [[login.someid|+]]. In my main site, I even use a
> config option to use a realname data value rather than some obscure
> member id. Very nice. But if there is no login page, you won't have
> any pages to link to. There are other shortcuts also to profile info,
> like {~id} as I mentioned. above. Nothing that should break the
> system, just some fine tuning. Such as turning off a couple markup
> rules you wouldn't need.
>
> > If toolmapping or something like it can be activated by a plugin, it
> > might make implementing something like this simpler, allowing for
> > upgrades to the core as needed without having to redo everything each
> > time.
>
> > A plugin would also help others I think by providing a shell of how it
> > can be done that could be used by others that need to integrate like
> > this.
>
> That's correct. If it is something that might have broader appeal, by
> all means, put it in a plugin and make it available in the solutions
> area. If it is something specific in your site, you may prefer to put
> it in a single config.php file. On my main site (www.fast.st) I have a
> lot of very custom code for various functions, conditions, side menus,
> the like. All of that is dumped in one big config file. Tidier than a
> bunch of plugins, though I do use plenty of those as well. :)
>
> Cheers,
> Dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
