Okay, RoR is pretty cool. In about a couple of hours I have secured my login and activation. I found all of the places to customize and have done so, and I put in some pretty colors. It's amazing because when I was working in WebObjects I thought about how much I wanted to abstract things. I worked hard to make the WO version be as flexible as possible so that changes only were needed in one location and those locations were logically organized. The original developer and those continuing to extend rails obviously think along the same lines. Here's what I've been using so far and like:
Flash. Flash is really cool. You use it to pass messages from the controller to the next page displayed. It works as a hash , so you associate a string with a key. One standard is to use :notice as a key for messages to the user, and :error for error messages. What makes this awesome is that I can place <%= flash[:notice] %> in my page and whatever message gets passed will pop right in there. Wrapping a css class and span around that lets me control the format of these messages on every page. I set this up on my login page for the standard "username/password incorrect" message. Later, when I locked down the user's home page and sent a redirect to login, "you must be logged in to do that" showed up in the same spot, looking exactly the same! I think this is part of the fun that RoR gives a programmer. One of the best feelings of programming is when you what something to happen, you code something to happen, and it does. I know that sounds stupid, but ask a programmer and he will agree. What is even cooler, is when you want something to happen, you don't code it to happen, and it does anyway!
Another thing I like is the inheritance hierarchy. RoR was designed for maximum flexibility, and the inheritance structure provides it. Placing items in the superclasses provides for everyone. You want it to be specific? Put it in the subclasses. My only worry is that this won't be so easy with Models. I will have to see.
I did run into a problem with something I've had an issue with all along. The separation of migrations and model files seems so un-Rails like. I added on to the User class to allow a boolean to hold email preferences. For some reason the boolean wasn't getting set from the form. Eventually, I realized that I also needed to add it to some code in the model file. This is stupid. I should only have to declare my columns and properties in one place. I do not think that the benefit of backtracking migrations outweighs the ease and intelligence of single location editing of models. They're models! What language requires you to define classes in two places (okay, leave C++ out of this)?
Authentication is just about finished for now. Down the road I am going to want roles, but for now a simple Admin boolean will suffice. I should program up some more functional and unit tests, but I'm too lazy and I want to start playing with some Avatars. Mmmm... Character Creation is on the menu!
Thursday, December 6, 2007
Wednesday, December 5, 2007
You've got Authentication!
After working a bit with my user authentication/management system, I figured that someone has probably done this before, and done it better. In all likelihood, my system would be highly vulnerable to well-known attacks and never be secure enough nor cool enough. Plug-ins are a double-edged sword. They can be dangerous because the programmer doesn't learn anything by using them, causing them to become more ignorant about the language and technology, and thus requiring more reliance on more plugins. But they can also be helpful. They can save time when the task is something simple, and can provide a novice to the technology (like I am) the ability to see how things should be done. Also, an open-source approach is always more secure because hundreds or thousands of eyes have had a chance to look over things. This was what made me decide to seek some outside help for my authentication system.
At first I looked through the wiki, and found the page on authentication. Many different plugins and approaches are listed there. I first chose Act_as_authenticated since it included everything I wanted and seemed to be the most complete. When trying to install that, I found that it had been replaced by the author by a new version called Restful_authentication. And then I fell down the rabbit hole of RESTful.
RoR development is fun because it is so new. Someone can post an idea and 3 months later everyone is depending on it like God Herself decreed that it was the best way to program. There are mini fads within this fad of a programming technology! RESTful is one of those. Actually, I don't know if its a fad, because it makes sense. It deals with handling access by putting access to data behind a single URI and sorting out based on HTTP protocol. This makes sense. Really, it is pretty much what Rails should have been doing the whole time rather than using the long chain within the URI (and including the id number? Ewww!). I always had a problem with that.
Now I have my plugin, and I know why its cool, next step is to install and test it. I made a separate app for testing to make sure it all worked. I'm glad I did because there was a bunch of setup stuff required, and I feel better getting it right in my test app before putting it all in my app. Once I got everything figured out, I looked at my current version of V and noticed that really all it had was the user stuff that I was going to replace anyway, so I renamed that for historical reasons (future historians are going to love me) and made a new app. Here's what I did after that:
That sets things up. Next, make a call to migrate to add the new db stuff and then start up the server and check out /signup. There is a lot more configuration and customization to be done. But it works! And it seems to be pretty robust.
I'm on a kick of extreme programming, so I want to have my authentication system complete before I move on. That means that customizing the interface is next!
At first I looked through the wiki, and found the page on authentication. Many different plugins and approaches are listed there. I first chose Act_as_authenticated since it included everything I wanted and seemed to be the most complete. When trying to install that, I found that it had been replaced by the author by a new version called Restful_authentication. And then I fell down the rabbit hole of RESTful.
RoR development is fun because it is so new. Someone can post an idea and 3 months later everyone is depending on it like God Herself decreed that it was the best way to program. There are mini fads within this fad of a programming technology! RESTful is one of those. Actually, I don't know if its a fad, because it makes sense. It deals with handling access by putting access to data behind a single URI and sorting out based on HTTP protocol. This makes sense. Really, it is pretty much what Rails should have been doing the whole time rather than using the long chain within the URI (and including the id number? Ewww!). I always had a problem with that.
Now I have my plugin, and I know why its cool, next step is to install and test it. I made a separate app for testing to make sure it all worked. I'm glad I did because there was a bunch of setup stuff required, and I feel better getting it right in my test app before putting it all in my app. Once I got everything figured out, I looked at my current version of V and noticed that really all it had was the user stuff that I was going to replace anyway, so I renamed that for historical reasons (future historians are going to love me) and made a new app. Here's what I did after that:
- Install the plugin.
This one's easy. First link to the URL:
script/plugin install
Then install:
script/plugin install restful_authentication - Generate the model.
Restful_authentication is a generator plug-in, so it works like scaffolding where you make one call and it builds lots of stuff.
script/generate authenticated user sessions --include-activation
The first parameter (authenticated) tells the generate script to use restful_authentication's generator. The second parameter is the name of the model and the the third is the controller name for handling log in and out. This call will create a new model called user that will be used to hold all of the user's data. It also creates controllers that handle signup, login, and logout as well as some minimal views for the functions. You also get functions to use as filters for testing the current authentication status. By adding --include-activation on the end, e-mail activation code is included so that the system can e-mail the user and have them activate their account through e-mail. I'm going to use this since I want to make it difficult for people to have lots of accounts, so I want to force each one to have a real e-mail address. - Setup the routes.
This was a little tricky, even though the docs did give me just about all of the info I need. Here's all of the things I added to routes.rb to get it working. Remember that these go before the map.connect lines:
# for restful_authentication
map.resources :users
map.resource :session, :controller => 'sessions'
map.signup '/signup', :controller => 'users', :action => 'new'
map.activate '/activate/:activation_code', :controller => 'users', :action => 'activate'
map.login '/login', :controller => 'sessions', :action => 'new'
map.logout '/logout', :controller => 'sessions', :action => 'destroy' - Setup the environment.
The activation mailer uses an observer to watch for the creation of a new user. Put this into environments.rb in the run method:
# restful_authentication
config.active_record.observers = :user_observer
To send the e-mail, I want to use sendmail since I'm developing just on my mac, and don't happen to have an SMTP server setup. However, this might change when V goes into production, so I'm going to tell my ActionMailer to use sendmail only during development. I put this in environments/development.rb.
# tell ActionMailer to use sendmail
ActionMailer::Base.delivery_method = :sendmail
God I love RoR!!! - Give everyone access to the authentication methods.
The user_controller and session_controller have AuthenticatedSystem included at the top of them with a note to put this in ApplicationController. This way, everybody gets access to the methods that test for authentication. So take those lines out of user_controller.rb and session_controller.rb and put this at the top of application.rb:
# Authentication methods for restful_authentication
include AuthenticatedSystem
That sets things up. Next, make a call to migrate to add the new db stuff and then start up the server and check out /signup. There is a lot more configuration and customization to be done. But it works! And it seems to be pretty robust.
I'm on a kick of extreme programming, so I want to have my authentication system complete before I move on. That means that customizing the interface is next!
Monday, December 3, 2007
V 6.0
And so I start over again... again.
It turns out that the WO stuff for Eclipse wasn't that great after all. The EOModeler replacement had its issues, the SQL code never worked, and I couldn't get Java classes generated from my EO Models. I was facing a re-write of all of my previous work, with a sub-par alternative to sub-sub-par tools, and on a less-than-lean system that I was going to have issues deploying.
With those issues looming, I looked at a change of technology... again.
And so V was reborn. This time it was red and shiny and had thick iron guides. Yes, V has jumped on another fad, this time to Ruby on Rails.
I did plenty of reading before deciding to change. Lack of documentation is one issue that the RoR community is trying to fix. Many of the intro docs go through quick set-ups and overview the creation of mini-projects to show off how quickly you can start working with rails. There are few docs that provide full details of what is going on behind the scenes, or that outline the full set of information. To learn RoR, you have to schlep through these tutorial guides until you learn enough so that you can tackle the API's. That's about all you can do.
I'm still not sure if RoR is the best fit for V. RoR is designed for more casual web applications. Ruby is a tougher language for business logic than Java is and the Rails tools are designed for more strict CRUD (Create, Read, Update, and Delete) access to data. V is a game. Users log in and fight monsters and spend gold on items. It's mostly business logic (yeah, the business of kicking monster ass) and data management isn't as big of a deal. However, there are some really great things that I get with RoR. While Java would be better for the logic programming, Ruby has some awesome OOP stuff including introspection, wacky overriding, and reflection. Unit testing and functionality testing is built-in. While it takes a while to get used to the rails directory and file structure, and you are forced a bit to do things the "rails way" (hence the appropriate title), it uses easy to read pure text files in a standard format. This is such a nice thing to have after WO.
After research, the next step was installation. The steps to install Ruby on Rails on OSX Leopard are as follows:
Did you catch that? It's already installed! Apple chose to include RoR in Leopard. If you have the developer tools installed, you don't have to do a thing.
For the past couple of weeks I have been playing with RoR. I made the usual user sign-up and login/logout as a tutorial/trail. However, now I'm experimenting with using a plug-in that will do it all for me (I'll keep you posted with what I find). I'm getting used to some of the things. There are some things I like (strict MVC, easy agile development, standard naming conventions) and some things I hate (migrations vs. models, too many places to define things, standard naming conventions). The one that beats out the rest is the agile development. It's easy to do piecemeal development, which fits hobbyist programming like this. The best part is how comfortable I feel working with one small bit at a time, knowing I don't need to plan my entire object or DB structure ahead of time.
I'm also starting to re-define the purpose of V. I also have been thinking about how I want it to look. I'm imagining the look of an old map. More details on this to follow
It turns out that the WO stuff for Eclipse wasn't that great after all. The EOModeler replacement had its issues, the SQL code never worked, and I couldn't get Java classes generated from my EO Models. I was facing a re-write of all of my previous work, with a sub-par alternative to sub-sub-par tools, and on a less-than-lean system that I was going to have issues deploying.
With those issues looming, I looked at a change of technology... again.
And so V was reborn. This time it was red and shiny and had thick iron guides. Yes, V has jumped on another fad, this time to Ruby on Rails.
I did plenty of reading before deciding to change. Lack of documentation is one issue that the RoR community is trying to fix. Many of the intro docs go through quick set-ups and overview the creation of mini-projects to show off how quickly you can start working with rails. There are few docs that provide full details of what is going on behind the scenes, or that outline the full set of information. To learn RoR, you have to schlep through these tutorial guides until you learn enough so that you can tackle the API's. That's about all you can do.
I'm still not sure if RoR is the best fit for V. RoR is designed for more casual web applications. Ruby is a tougher language for business logic than Java is and the Rails tools are designed for more strict CRUD (Create, Read, Update, and Delete) access to data. V is a game. Users log in and fight monsters and spend gold on items. It's mostly business logic (yeah, the business of kicking monster ass) and data management isn't as big of a deal. However, there are some really great things that I get with RoR. While Java would be better for the logic programming, Ruby has some awesome OOP stuff including introspection, wacky overriding, and reflection. Unit testing and functionality testing is built-in. While it takes a while to get used to the rails directory and file structure, and you are forced a bit to do things the "rails way" (hence the appropriate title), it uses easy to read pure text files in a standard format. This is such a nice thing to have after WO.
After research, the next step was installation. The steps to install Ruby on Rails on OSX Leopard are as follows:
Did you catch that? It's already installed! Apple chose to include RoR in Leopard. If you have the developer tools installed, you don't have to do a thing.
For the past couple of weeks I have been playing with RoR. I made the usual user sign-up and login/logout as a tutorial/trail. However, now I'm experimenting with using a plug-in that will do it all for me (I'll keep you posted with what I find). I'm getting used to some of the things. There are some things I like (strict MVC, easy agile development, standard naming conventions) and some things I hate (migrations vs. models, too many places to define things, standard naming conventions). The one that beats out the rest is the agile development. It's easy to do piecemeal development, which fits hobbyist programming like this. The best part is how comfortable I feel working with one small bit at a time, knowing I don't need to plan my entire object or DB structure ahead of time.
I'm also starting to re-define the purpose of V. I also have been thinking about how I want it to look. I'm imagining the look of an old map. More details on this to follow
Subscribe to:
Posts (Atom)