Main Stories
Slash Boxes

Slash Open Source Project

Slashcode Log In

Log In

[ Create a new account ]

Article Poll

Poll I found this article to be
Very Helpful
Helpful
Not Helpful
Not Very Helpful
[ Results | Polls ]
Comments:0 | Votes:0

Learning Perl for Slash... where next?

posted by Krow on 11:40 AM November 12th, 2001   Printer-friendly   Email story
dscottj writes "I want to alter slashcode, but don't know perl. I've read Learning Perl and did all the exercises, but I am only slightly less clueless when I look at the slashcode. Where do I go next?

I've also got Programming Perl. However, I'm not a CS grad... I'm self-taught using the not-quite-toy language ColdFusion. The camel book strikes me as being intended for people who already know what the hell they're doing with a real language. Unfortunately, I don't, and this book makes my head hurt after awhile. No practice examples also means that while I may understand what I'm reading, it doesn't stick with me.

I've also got The Perl Cookbook. It's better than the camel book for my purposes, but doesn't really seem to be meant for someone that wants to learn what makes the language tick.

And yes, I know about perldoc. However, every bit of documentation I've found on standard modules (because the slash modules don't seem to me all that well documented) seems to be targetted at someone already very familiar with the language. I'm not, and so I tend not to find the module documentations very useful at this point.

I'm trying to eventually be proficient enough to do this:

  • Create a "primary login screen" where a user enters their username & password before being granted access to the slash site.
  • Use this login info to authenticate against my existing LDAP directory
  • Use this username to see if this person exists in the slash users table. If they don't, add them. If they do, get whatever info is needed to "bake" the user cookie. My thinking here is that it will minimize the number of changes I have to make in the slash code. The user's UID is (understandably) used in many different tables, and it strikes me as a lot of work to figure out how to do without the users table entirely.
  • Figure out how to actually "bake" the cookie slash uses to store user info and do it before granting access to the site.
  • Check to make sure that slash will accept the cookie without ever requiring someone to log in. I think it will, but again I'm nowhere near skilled enough at this point to be sure.
So that's my primary goal right now. Not that anyone would want them, but I plan on submitting my changes back to you folks, if nothing else to give examples of how not to program in perl.

Any advice, resource recommendations, books to read, etc. would be greatly appreciated. Implying that I'm stupid isn't, because I already know that. :)"

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.
  • I will definitely be working on #1 and #2 in your list above for a site I am developing, although I will probably be authenticating against a NIS database.

    You probably don't need Perl for the authentication part: what I have in mind for my site is to use Apache authentication (.htaccess files and htpasswd). I haven't tried anything yet so I don't know if this approach will work. If it does, you can export you LDAP users and passwords to a htpasswd file (or have Apache authenticate users directly from the

  • by Anonymous Coward
    Perlmonks.org [perlmonks.org] is good for beginners and saints alike. There's a metric fuck-ton of information and examples there, plus real world problems and sample solutions.
  • >Create a "primary login screen"

    You could use an apache handler type thing that would redirect anyone w/o a logged in cookie to /login.shtml. Look at the one I did, with Krow's help, for an older version of slash. (url below)

    >against my existing LDAP directory

    I'd be interested to see how you end up doing this.

    >Use this username to see if this person
    >exists in the slash users table.

    Slash already checks for duplicate nicknames.

    >"bake" the user cookie.

    huh?

    >Check to make sure that slash will accept
    >the cookie without ever requiring
    >someone to log in

    ie automatic login? slash already does it. if you change the cookie, just make sure you don't mess with that the code that sets it up currently.

    >Any advice

    Yep, start reading, or hire someone to do all this for you.
    --
    lottadot [lottadot.com]
    • Re: "baking a user cookie"

      There are 5 functions in the Slash::Utility module:

      • getCurrentCookie
      • createCurrentCookie
      • bakeUserCookie
      • eatUserCookie
      • setCookie
      However, this is probably representing how little I understand of how slash works with users. My thought was that authentication works like this:
      • User enters username & pwd into login box and presses "submit".
      • [some perl magic happens] and a cookie is created with user information, then given to the user's browser
      • Every time it matters, slash looks for the cookie and if it sees it, uses that info. If it doesn't, a login can be performed again.
      My thought was that if I could figure out how to "bake" that cookie myself I could create my login system without having to take slash half apart.

      From reading other comments, it may be my lack of apache knowledge that is holding me back in addition to my lack of perl knowledge. More books... any recommendations?

      However, after digging some more the function prepareUser may actually do what I want all by itself. I will have to examine it more.

      Thank you for your help and advice. I apologize if this has been discussed on either mailing list previously, as the search functions on those archives haven't worked since I've been dinking with slash (2 months or so).

      • > From reading other comments,
        > it may be my lack of apache knowledge
        > that is holding me back in addition
        > to my lack of perl knowledge.

        Well, you are not alone. Slash is a wonderful application, but it requires some time to understand and master. I do know a little bit of Perl and Apache and I still struggle when I want to do some basic things that can't be done out of the box.

        >However, after digging some more
        >the function prepareUser may
        >actually do what I want all by
        >itself. I will have to examine it more.

        This is a very good idea. I think this function is key.

        >Thank you for your help and advice.
        >I apologize if this has been discussed
        >on either mailing list previously,
        >as the search functions on those
        >archives haven't worked since I've
        >been dinking with slash (2 months or so).

        No need to apologize, we've all been there before, and some of us are still there :-)

        Stop by #slash on OPN. People there are busy coding the next generation Slash, but they are willing to help if they have some spare time.

        Eloy.-