Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Inner Scriptorium

( #389873=superdoc: print w/ replies, xml ) Need Help??

This section is used by the Cabal in plotting improvements to the inner workings of the Monastery's raw sewage macerator, boiler room, nuclear reactor, and cold fusion pump. Cabal only may post root nodes to this section. But fresh thought often spawns progress, so any Perl Monk may add comments to existing discussion threads within this section.

Please remember that Monastery related discussions of global interest to the general PerlMonks population should be entertained in the Perl Monks Discussion section. gods can and will remove off-topic content from the Inner Scriptorium.

Inner Scriptorium
bringing nodelets out of the shed
No replies — Read more | Post response
by jdporter
on Jan 18, 2011 at 10:50

    Thinking about how to blur the distinction between nodelets and regular nodes, so that you could, for example — theoretically — embed a regular node into your page like a nodelet, or — more practically — view a nodelet as a standalone ("regular") node.

    Nodelets are special in the following ways:

    • they have a designated "container", which is essentially HTML template code which gets wrapped around the nodelet's contents at display time;
    • they have the concept of periodic updating, with caching of contents in between updates.
    • they can be selectable for inclusion in your list of displayed nodelets.

    Aside from that, they are essentially superdocs: documents which can contain code for performing various functions. There is no technical reason why a nodelet could not be viewed standalone, just like any other superdoc.

    Therefore, as a proof of concept, I created nodelet view page, a displaypage which does exactly that. To try it, view any nodelet and add ;displaytype=view to the URL. For example, your XP Nodelet.

    It works. However, there are obviously some caveats. For example, viewing your Free Nodelet in this way is likely to cause mayhem if you have any javascript going on in it.

    Now, if we can get this code to be ready for prime time, I would recommend making this the default view for nodelets, and migrating the current default view into the viewcode htmlpage. That is:

    1. rename nodelet display page as nodelet viewcode page, then
    2. rename nodelet view page as nodelet display page.

    Then a pmdev simply clicks on the "code" link which will appear at the top of the nodelet display page to get to a point where its code can be examined/patched.

    One further kewlosity: add /bare/ to the path part of the URL to get a nifty little ticker-like form (html, not xml) of any given nodelet. Example: your XP Nodelet. (It's not really a ticker; it doesn't auto-refresh.)

    I also have a patch (expandfreenodelet - (patch)) for embedding any given nodelet's contents into your Free Nodelet. I'd like to know if this might have potential problems. It seems like a cool idea to me.

    What is the sound of Windows? Is it not the sound of a wall upon which people have smashed their heads... all the way through?
Password shtuff
1 direct reply — Read more / Contribute
by ysth
on Dec 30, 2010 at 14:55
    Rough notes on a chatterbox discussion.

    How about md5 crypts instead of password in the cookie? That would allow passwords > 8 chars (with a user table change).

    md5 may be too CPU expensive; needs to be tested.

    An md5 crypt certainly takes more time than a des crypt: one some machine the md5 crypt seems to take 5e-4 second, the des takes 1.3e-5 seconds.

    (comments about $3$/NT-hash)

    Instead of comparing hashed password in cookie to hash of clear password in database, store the hashed password in the database and the non-salt part of it in the cookie; authenticate cookies via string compare.

    Later, unhashed password will be eliminated.

    update user edit page to require the previous password in order to change the password

    have a real "password reset e-mail" feature

    A math joke: r = | |csc(θ)|+|sec(θ)|-||csc(θ)|-|sec(θ)|| |
    Online Fortune Cookie Search
New pmdev-only documentation infrastructure
4 direct replies — Read more / Contribute
by jdporter
on Dec 03, 2010 at 13:01

    Following up on previous thread Pmdev documentation...

    I've been cogitating a bunch upon this idea of using sitedoclets to document code, i.e. infrastructure nodes.

    Currently, sitedoclets can be attached to infrastructure nodes of the following types:

            Update '10/12/22; see below

    Anyway, I've come up with what I think is a pretty good idea, so I'd like to run it by you all, see what you think.

    My idea essentially is this: have a new nodetype, devdoclet, which would be used to document the purpose and usage of infrastructure nodes. In particular, it would be a great place to note the status of nodes such as dead, live, experimental, and not-yet-live htmlcodes .

    devdoclet is like sitedoclet in most ways, except that,

    1. It is owned (creatable, editable) by pmdev rather than SiteDocClan, and would not be intended for general public consumption.
    2. More importantly — there is an explicit policy which supports bi-directional links, implicitly by title, between an infrastructure node and its devdoclet.

    That is, the doclet for (say) parselinksinchatter is necessarily parselinksinchatter devdoclet. (It would therefore be slightly different from the sitedoclet situation, where this nomenclature is conventional but not universal nor enforced.)

    This enables certain very convenient things — most obviously, that a pmdevil can navigate from a devdoclet to its associated code node simply by stripping off the " devdoclet" part of the title. (Of course, we'd automate this for you by means of a link in your pmdev nodelet.)

    I also envision a structure, perhaps somewhat like the sitefaqlet/faqlist nested-listy thing, for knitting all the devdoclets into a whole "site infrastructure document"... as touched on in the earlier thread. And note that it would also be possible to make devdoclets which are not linked to specific infrastructure nodes; these could be used to document overarching concepts and like such as.


    What is the sound of Windows? Is it not the sound of a wall upon which people have smashed their heads... all the way through?
Dup Nodes/Server Glitches?
2 direct replies — Read more / Contribute
by ww
on Mar 17, 2010 at 07:32
    Server glitches implicated in some dup posts? hasn't attracted much comment in the thread itself, but /me has received several private replies which seem to support the hypothesis therein.

    In brief, my notion is that one symptom/by-product/whatever occuring when pm is overloaded/slowed-for-whatever-reason, users tend to experience inadvertent creation of dup posts.

    Perhaps this note will intrigue a more highly skilled dev to confirm (and fix?) or refute my suspicion.

Create new [pmdev]-only section "Pmdev Discussion"
2 direct replies — Read more / Contribute
by jdporter
on Aug 21, 2009 at 17:25

    The idea would be to create a section, rather like Perl Monks Discussion, but which would be accessible (both read and write) only to pmdev, for the purpose of discussing ... well, anything pmdev wants to discuss internally. This is to get away from using the wiki for such discussions, since — as has been pointed out on several occasions — wikis are not a good medium for discussion. Looking at the history of wiki rollovers, it's clear that a lot more has gone on in the pmdev wiki than any other, and undoubtedly most of that volume was for discussions.

    What do y'all think of this idea?

    It would be pretty easy to do. The steps involved would be as follows:

    1. Clone pmdevtopic into pmdevroot as a subnodetype of pmdevtopic, setting Creator=Updater=pmdev.

    2. Make a pmdevroot display page like so:

    <p><i> [% linkNode $$NODE{author_user}; %] has initiated the following pmde +v topic: </i></p> <p> [{parselinks:doctext}] </p> <p> [{editinvote:Your Topic}] [{shownote}] </p> <p><center> Back to [% linkNodeTitle('Pmdev Discussion') %] </center></p>

    3. Make a new section superdoc like so:

    [{get_sitedoclet}] [{newlistapproved:pmdevroot,perlquestion approved linktype,Pmdev Discu +ssion,15,navbaron,showall}] [{addnewform:pmdevroot,Initiate Pmdev Discussion}] [{showhints}]

    4. Other ancillary things, such as adding awareness of the new section/nodetype to Newest Nodes (for pmdev only, of course).

    It might be nice to name this new type "pmdevtopic", but that nodetype name is already used, by root posts of the Inner Scriptorium. We could rename that nodetype, to something like "manuscript" (in keeping with that section's name), freeing up "pmdevtopic" for the present purpose. tye says that such a renaming would take about 12 patches.

    Note that the reply node type already exists: pmdevnote.

Steps for the migration to hashed passwords
1 direct reply — Read more / Contribute
by Corion
on Aug 12, 2009 at 12:18

    The following list details (IMO) the steps necessary to move from plaintext passwords to storing hashed passwords, and also moving the infrastructure (password resets, initial sign-up etc.) to accomodate hashed passwords. All steps can be taken without interruption. I'm not sure if my approach of using hashes for "activation" and then resetting the password only when that "activation" hash is submitted, together with the appropriate user id in the appropriate timeframe is sensible.

    Discussion of the approach and/or the other changes is very much welcome, as is a discussion of what I named things. I'm bad at naming things, especially.

    1. Table pending_activations ("new user entries", "password reset entries")
      1. user_id (for password resets)
      2. username (for new user signups)
      3. activation_hash
      4. expires default now()+12hr (MySQL 5.0, which we use, does not allow functions for default values :()
    2. Add a password hash column to the user table
    3. superdoc: activate_user( Int $user_id, Str $activation_hash )
      1. check user_id+activation_hash in pending_activations
        select user_id from activate_user where user_id = :$user_id and activation_hash = :$activation_hash and expires > now()
      2. generate fresh password
      3. hash = &generate_password_hash( $USER, $passwd )
      4. store fresh password in user table
      5. store fresh hash in user table
      6. store fresh password in $USER
      7. send login cookie that's valid for this browser session
      8. display fresh password to user
      9. display link to "Log me in and give me a permanent cookie" (expiry=never)
    4. htmlcode: generate_password_hash( $USER, Str $passwd )
      1. generate hash from password+username+secret sauce
    5. htmlcode: generate_activation_hash( $USER, Int expiry )
      1. generate random hash
        INSERT into pending_activations user_id, hash, expiry
      2. return hash
    6. User settings user edit page:
      1. hash = &generate_password_hash( $USER, $passwd )
      2. store hash in user table
      3. set cookie to hash
    7. Everything/
      $hash = &generate_hash( $USER, $passwd ); # ... confirm via hash my $ok = $hash eq $USER->{passwd_hash}; # if the hash-compare failed and the user still has a password, us +e that: if (defined $USER->{passwd}) { ... confirm via passwd }
    8. htmlcode: generate_activation_link( $USER )
      1. hash = &generate_activation_hash( $USER )
      2. return abs_url($settings{site_url}/?node_id=activate_user;user_id=$USER->{id};hash=$hash)
    9. Activation

      1. add hash column to user table
      2. populate hash column by generating the hash from the passwd if it's not NULL
    10. new user mail (975)
      1. don't display password
      2. display activation_link resp. change the template to generate the activation link
    11. Password Mail (2514):
      1. don't display password
      2. display activation_link resp. change the template to generate the activation link
    12. Deactivation of passwords
      1. set passwd to NULL
      2. remove code for storage of passwd from activate_user()
      3. drop passwd column from user table after all users have been migrated (select count(user_id) where passwd is not null) == 0

    Update: Corrected node links, added topics as per ig's reply below

    Further Update: Found out that MySQL doesn't support functions in default values. Changed names to fit reality.

Pmdev documentation
3 direct replies — Read more / Contribute
on Aug 05, 2009 at 02:10

    Recently I compiled an annotated list of all of the database tables used by the PerlMonks website (see PerlMonks Data Model). bobf has expressed an interest in collaborating on it with me and I think that is a wonderful idea. In fact, we'd like it if we had an entire collection of pages that pmdev's could add remove, and edit as a group without godly intervention.

    As anyone who checks the data model on my extra scratchpad will note, it is nearly at the 64K limit and there is still much information to add. It badly needs to be broken up into subsections, each with their own page. And of course those pages need to be communally edited. It would be even better if (a) we could see an edit history of all edits with undo, redo ability (b) we could assign pages to multiple categories and have category lists auto-generated (a la mediawiki). We have found both those features extremely useful on large collaborative documentation projects (including the mediawiki documentation itself!).

    A collaborative environment for pmdev documentation could also be used for much more than just the annotated data model on my extra scratchpad. The documentation for pmdev is scattered in many places, including the wayback machine. A collaborative documentation environment would let us consolidate the existing documentation into an internally consistent corpus and make it easier to keep it up to date.

    The ideal environment for collaborative pmdev documentation may require some work. In the meantime, bobf and I are eager to get to work and we already have some things that come pretty close to what we need. As an initial first step, we were wondering if we could copy the infrastructure used by SiteDocClan to create a set of internal pmdev documentation parallel to the public site documentation?

    This would involve creating the following new nodetypes:

    • DevFaqlet:: similar to sitefaqlet. These would be used for group edited documentation pages. pmdev's should have full rights to add, delete, and update the pages. Deleting is important because leaving around irrelevant documentation can be very confusing. When pages are broken down into subpages, one doesn't always get the arrangement right the first time. It is important to be able to reorganize information easily without leaving the old not-so-good organization lying around. The cabal should have read access.
    • DevFaqlist: similar to faqlist. These would be used to thematically group devdoclets. pmdevs should also be able to add, remove, and edit these lists at will. The cabal should be able to read them.
    • DevFaqstring: similar to faqstring. Again, pmdevs should also be able to add, remove, and edit these at will. The cabal should be able to read them.

    Using existing infrastructure also has another advantage. As we begin working on documentation together, our ideas about what we really need will take a firmer form. Once we have more experience working together, we can reopen the issue and discuss requirements with more clarity.

    Best, beth and bobf

Free Nodelet Hack: Current Node Alternate Views and Info
2 direct replies — Read more / Contribute
by jdporter
on Aug 04, 2009 at 07:31
    <b>This node:</b> createtime: `createtime`<br> &#91;id://`id`] [href://?node_id=3333;parent=`id`|replyto] [href://?node_id=`id`;displaytype=xml|xml] [href://?node_id=`id`;displaytype=raw|raw] [href://?node_id=`id`;displaytype=viewcode|code] [href://?node_id=`id`;displaytype=edit|edit] [href://bare/?node_id=`id`|bare] [`id`.xml|rss] [href://?node_id=`id`;displaytype=edithistory;limit=25|rje] [href://?node=`title` sitedoclet|doclet] <a href="`url`" id="page_url">url</a> [`id`.xml|orig.xml] [href://?recipient=`id`;type=strangedoc;node=message%20inbox|inbox] <br> <form method="post" action="?" enctype="application/x-www-form-urlenco +ded"> Search in code: <input type="hidden" name="node_id" value="157620"> <input type="hidden" name="sexisgood" value="submit"> <input type="text" name="searchterms" size="40" id="codesearch"> <a href="/?node_id=157620;searchterms=`title%`">or "`title&`" directly +</a> </form> <br> type: &#91;id://`type_id`|[id://`type_id`|`type_title`]] [href://?node +_id=106927;whichtype=`type_id`|Node lister]<br/> parent: &#91;id://`parent_id`|[id://`parent_id`|`parent_title&`]] [hre +f://?node_id=`parent_id`;displaytype=xml|as xml]<br/> root: &#91;id://`root_id`|[id://`root_id`|`root_title&`]] [href://?nod +e_id=`root_id`;displaytype=xml|as xml]<br/> author: &#91;id://`author_id`|[id://`author_id`|`author_title&`]] last +here: `lasthere`; lastupdate: `lastupdate`; [href://?node_id=6364;user=`author_name`|writeups]; [href://?node_id=434853;editor_user=`id`;filter=only;Wi=1;SDC=1;Ped=1| +author's RJE]; [msg://`author_id`|/msg]<br/> lastedit: `lastedit` (doc; null) (pretty much just [wiki]s)<br> <!-- nodeupdated: `nodeupdated` (node; null) (used for patches)*<br/> *code exists to update <tt>nodeupdated</tt> when a node's hit count is + updated.<br/> --> <br> group: `group` <br>

    Updated with planetscape's suggestion and some other ideas; deleted cruft; rearranged.

    Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.
Log more events in the edithistory?
1 direct reply — Read more / Contribute
by jdporter
on Jun 05, 2009 at 18:08

    Currently, the edithistory (i.e. that data displayed by Recent Janitorial Edits) is only used for logging edits to the document content of nodes (under certain circumstances). There are several other kinds of janitorial actions which do not get logged — for example, moving a node to a different section. I know there've been times when I wished this other kind of info was logged in the edithistory.

    I made one change recently in this direction; it could be called a proof of concept: if you move a node using the Moderation Nodelet (which, btw, is deprecated in favor of the Approval Nodelet), this gets logged.

    So, what do we think? Should we log more janitorial event types besides node content editing? If so, what types should we [not] log? And why?

    Update: Here is a list of the possibilities:

    1. Approve for section
    2. Unapprove for section
    3. Approve for front page
    4. Unapprove for front page
    5. Move (root) to other section
    6. Reparent (make it a reply of another node)
    7. Promote (convert a reply into a root)
    8. Added 2015-07-07:
    9. Unconsider. Capture the details of the consideration; otherwise they'd vanish without a trace. (user, reason, date. maybe votes?)
    (Please /msg me if I've missed any.)

    IMHO, we almost certainly do not want to log #1 and #3, as those are far too numerous, and of relatively little importance. And at any rate, the info on a node's current approval status is already being stored elsewhere.

    Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.
RFC: Rename all group wikis to the form "(GroupName) wiki"
2 direct replies — Read more / Contribute
by jdporter
on May 05, 2009 at 14:09
Log In?

What's my password?
Create A New User
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (5)
As of 2015-12-02 04:27 GMT
Find Nodes?
    Voting Booth?

    My keyboard shows this many letters:

    Results (34 votes), past polls