Hi!
I’m planning a booking system in rails, and I have the following issue:
There will be room_types. I can implement this with STI in the rooms
table, or with a separate table room_types. Each room type will have its
special features.
For example, a double room can be:
Sorry, but I used ruby-forum to post, and used the TAB key and then
space, so i submitted by accident :S.
Please, read the 10.minutes.from_now post ^^
Rodrigo A. wrote:
Hi!
I’m planning a booking system in rails, and I have the following issue:
i remembered seeing this (http://www.solunas.org) when I saw your
question - might be worth a look
–
Mike G. email : [email protected]
Technical Director fax : +353 68 470 01
XL CRS mobile: +353 87 677 2055
Lisselton phone : +353 68 470 10
Listowel
Co. Kerry MSM : [email protected]
Ireland Y!M : [email protected]
I am about to embark on a project to implement an entire Information
system underpinning the entire operations of a company.
In order to heavily enforce security (be strictly defining what a
model can do in one app, and not in another) I am planning to
implement two rails apps. One will be the customer facing website
with booking engine, the other will be a secure administration area
(probably over HTTPS) with a lot more functionality but less of the
fancy graphics.
Can I put these two apps on top of the same database without causing
any massive problems?
Does anyone have any experience of this?
David
David S. wrote:
Can I put these two apps on top of the same database without causing
any massive problems?
Assuming that one application is read-only (mostly) and the other
read-write, which seems to be what you are indicating this shouldn’t
have any more problems than a single app system.
I’m not sure if the decision to split the project into two apps is
really a good one. You could build a single app with multiple front
ends depending on who is accessing the site. I’ve built an online shop
before, in PHP, where the system had three independant front-ends,
anonymous browsing, trade customer, administrator.
I imagine if I had built that site in Rails it would have been a lot
easier too 
On 17 Feb 2006, at 14:37, Dominic M. wrote:
Assuming that one application is read-only (mostly) and the other
read-write, which seems to be what you are indicating this shouldn’t
have any more problems than a single app system.
The problem will come in that users can edit their details/make a
booking etc. in one app. but staff could be accessing the same data
simultaneously (theoretically), although due to the number of
customers and the frequency of their interaction this might not
happen a lot.
I’m not sure if the decision to split the project into two apps is
really a good one.
The problem is that it is critical that features exposed to one set
of users are never even possibly accessible by the other users. This
is because the app is running their business. The customer facing
app is literally for bookings and marketing information.
I guess in theory if i was using acts_as_authenticated with a Role
based authentication systems then I could ensure that end users were
never able to receive a “staff” role.
How do you manage the possibility that two staff could be modifying
the same data in the admin app? Concurrent access of data is a problem
even if you have a single app.
Does anyone know of a way that rails can handle this? Is it possible
to lock a record and then rescue any other attempt to access with a
custom error and redirect?
David
David S. wrote:
happen a lot.
How do you manage the possibility that two staff could be modifying
the same data in the admin app? Concurrent access of data is a problem
even if you have a single app.
based authentication systems then I could ensure that end users were
never able to receive a “staff” role.
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
–
Dominic
On Feb 17, 2006, at 6:30 AM, David S. wrote:
Can I put these two apps on top of the same database without
causing any massive problems?Does anyone have any experience of this?
David
David-
I do this for the newspaper web site I built. The public facing app
is read only. There are three other rails apps on our intranet that
connect to the same db and models for admin tasks. One for our survey
system, one for the cms admin system and one for the circulation
admin system. I haven’t run into any problems doing it this way at
all yet. It works great because the three internal admin apps are not
available outside out office LAN and so they have an extra layer of
security right there.
The model files are in the main public facing applications app/
models directory. the other admin apps symlink the model definitions
they need into their own apps tree. This way i only make changes to
the models in one place to share between all four apps. You should
use a lock_version column in all your shared database tables that can
get accessed by multiple apps. This way you don’t get stale objects.
This technique actually works very well. You could also put this all
in one application, but my app got too big and I found it much easier
to develop a standalone rails app for each specific admin section
then putting it all in one app tree.
Here is the site: http://yakimaherald.com
Cheers-
-Ezra Z.
Yakima Herald-Republic
WebMaster
509-577-7732
[email protected]
You could also package the shared code as a plugin or engine, and use
SVN externals to share that package between both applications.
On 2/17/06, Ezra Z. [email protected] wrote:
(probably over HTTPS) with a lot more functionality but less of the
David-
The model files are in the main public facing applications app/
Here is the site: http://yakimaherald.com
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
–
On 17 Feb 2006, at 17:39, Ezra Z. wrote:
The model files are in the main public facing applications app/
models directory. the other admin apps symlink the model
definitions they need into their own apps tree. This way i only
make changes to the models in one place to share between all four
apps.
I was thinking about using the model security plugin to protect
models that would never need write access to the db, so I’d probably
have to keep my models seperate. I wouldn’t anticipate this this
would be an issue (but might slightly violate DRY)
You should use a lock_version column in all your shared database
tables that can get accessed by multiple apps. This way you don’t
get stale objects. This technique actually works very well.
Can Rails handle an attempt to edit a locked object before someone
tries to hit save. ie. when someone opens up an object that someone
else is already editing, can they be notified via a flash or just not
permitted to edit. Or will I have to handle the stale object error
and inform the user what has happened?
In an ideal world, the app would inform the user trying to edit a
locked object that the current object was read only and they would
get a button to attempt a reload of the page.
David
Dominic M. wrote:
fancy graphics.
Can I put these two apps on top of the same database without causing
any massive problems?Assuming that one application is read-only (mostly) and the other
read-write, which seems to be what you are indicating this shouldn’t
have any more problems than a single app system.
Another thing you can do for some added security is check the IP address
of the user and only allow local users to access a page with something
like
if ((@request.remote_addr =~ /^192.168./) != false) then
< do stuff >
else
< error page >
end
in ether the controllers or in the views.
On Feb 19, 2006, at 3:20 PM, Neil D. wrote:
fancy graphics.
if ((@request.remote_addr =~ /^192.168./) != false) then
< do stuff >
else
< error page >
end
Wouldn’t it make more sense to use an application.rb
helper (available everywhere):
def request_is_local?
@request.remote_addr =~ /^192.168./)
end
Then the controllers can simply use:
if request_is_local?
< do stuff >
else
< error page >
end
DRY + readability == the right way
Another improvement would be to use before_filter
to make the call to request_is_local?
Perhaps even better is to override the built-in
local_request? then use that in the before_filter, which
gives you the advantage of Rails knowing a request is
local and responding appropriately in the case of errors.
Overriding a built-in is a bit much for a list response,
so here’s the URL to learn more:
http://api.rubyonrails.com/classes/ActionController/Rescue.html#M000043
I’m not sure if the decision to split the project into two apps is
really a good one. You could build a single app with multiple front
ends depending on who is accessing the site.
Yes, I’d agree here. No need for separate applications.
Put the secure stuff in it’s own controllers and own view, protect
it in several ways (user/password/role), HTTPS, IP verification,
etc. and DRY on the however you choose to protect it via before_filter
so that nothing in the administration controller(s) “slips through the
cracks.”
–
– Tom M.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs