Sorry... just figure it out... config is in the field directory...
I moved the config.php there, renamed the functions that I wanted to use as mylogin and myregister and it works. On Sun, Sep 20, 2009 at 5:32 AM, Kevin <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
