patch for bug in boss_db with postgres

[Guido Witmond]

Hi Everyone,

I've found a bug in boss_db:data_type/2 when using the postgresql
adapter. It shows up in cb_admin model as:

{function_clause,
[{boss_db,data_type,[salt,null],[]},
{cb_admin_model_controller,'-model/3-fun-1-',1,
[{file,

"/Users/guido/cb/cb_admin/src/controller/cb_admin_model_controller.erl"},
{line,38}]}, ....

The postgres-adapter returns a 'null'-atom while the function expects
'undefined'.

This small patch against 0.7.4 allows for null-atoms as well.

Feel free to add to the codebase.

Guido Witmond.

[Evan Miller]

Hi Guido,

Would you mind sending this patch (and your other patches) as pull
requests via GitHub? That way I can keep track of where code came
from. Looks good though.

Evan

[Guido Witmond]

On 22-05-12 17:28, Evan Miller wrote:
> Hi Guido,
>
> Would you mind sending this patch (and your other patches) as pull
> requests via GitHub? That way I can keep track of where code came
> from.

Will do!

Guido.

[Chris Hicks]

I feel like I should know this but haven't been able to find the answer to what I am looking for. Basically, I'm looking to have one public facing application, and multiple "private" applications running on the same server. The public application routes various requests to these private applications for various funcationality but only the server should be able to have access to them, nobody else should even be able to know they are there. What's the config look like for such an application?

Chris.

[Matt Husby]

Hi Chris,

I think what you are going to want to do is restrict traffic to those "sites" much like what is done with cb_admin.  Here is a quick overview of how to add other applications that are restricted:

https://github.com/evanmiller/ChicagoBoss/wiki/Admin-interface

You are interested in the {allow_ip_blocks, ["127.0.0.1"]}, part.

Matt

-- 

Matt Husby

[Evan Miller]

Note that allow_ip_blocks only applies to the cb_admin application.
For other apps you'll need to put logic into your before filters, see

http://www.chicagoboss.org/api-controller.html#auth

The IP-checking code from cb_admin can be found here:

https://github.com/evanmiller/cb_admin/blob/master/src/lib/cb_admin_lib.erl

Hope that helps.

--
Evan Miller
http://www.evanmiller.org/

[Chris Hicks]

This is why I love you guys, Always with the quick and accurate answers. I notice, however, that allow_ip_blocks is not listed under the Configuration options in the Wiki. Anyone object to my updating that?

Chris

---

Date: Sun, 27 May 2012 12:35:07 -0500
From: matt...@gmail.com
To: chica...@googlegroups.com
Subject: Re: [chicagoboss] Restrict application to serving only local requests?

[Chris Hicks]

Thanks, I'll work that into my application.

> Date: Sun, 27 May 2012 14:42:21 -0500

> Subject: Re: [chicagoboss] Restrict application to serving only local requests?

> From: emmi...@gmail.com
> To: chica...@googlegroups.com

[Chris Hicks]

Evan,

I was thinking about this some more and I would like to propose that this functionality be added, by default and behind the scenes, to all applications. Now I don't know the internals well enough to know how feasable this is but I think it could be valuable in helping to create private, reusable applications such as access controls that a developer might not want the outside world to have direct access too. I was thinking that the general flow would look like this:

An HTTP request is routed to someApp
  if(allow_ip_blocks is defined)
  {
    if(request not from IP allowed)
      return 404 by default (maybe something which could be modified in routes for custom reporting/functionality)
    else
      continue processing request
  }
  else
    continue processing request

I think it would make it a lot easier to build up a library of, private, reusable components which could be loosely coupled together to create a very complex website. Of course, if I'm wrong about that I would love to hear about why, because otherwise I'm going to be doing this very thing with the code I was pointed to earlier.

Chris.

---

From: silent_...@hotmail.com
To: chica...@googlegroups.com
Subject: RE: [chicagoboss] Restrict application to serving only local requests?
Date: Sun, 27 May 2012 13:01:33 -0700

[Chris Hicks]

I feel like I'm missing something simple with this one but I have these two files:

-module(forumCategory, [Id, Topic]).
-compile(export_all).
-has({forumForum, many}).

-module(forumForum, [Id, Topic, ForumCategoryID]).
-compile(export_all).
-belongs_to(forumCategory).
-has({forumThreads, many}).

And I am getting the following error when I try to start CB up:

{{badmatch,{error,[{"/home/chris/emuf/src/model/forumForum.erl",
                                        [{0,erl_lint,
                                          {unbound_var,'ForumCategoryId'}}]},
                                           ...

What am I missing?

Chris

[Graeme Defty]

Chris,

try

-module(forum_category,[.......


g
_________________________________________

[Chris Hicks]

Thank you for the reply. While I probably should stick with the underscore, as opposed to camel case, methods for my files in CB, making that change actually gave me the same result in the end. The problem was simpler than that even, I had capitalized the "D" in "ForumCategoryId" in the forumForum model and CB didn't like that.

---

Date: Mon, 28 May 2012 06:46:28 +0700
Subject: Re: [chicagoboss] Model error, unbound_var
From: graeme...@gmail.com
To: chica...@googlegroups.com

[Graeme Defty]

Hahahahahaha - live and learn.

Sorry about the wild goose chase :-)

____________________________________________________

[Daniel Connolly]

For a quick fix, I used this code in my controller:

before_(_) ->

  Ip = Req:peer_ip(),

  if

    Ip == {127,0,0,1} ->

      {ok, "localhost"};

    true ->

      {redirect, '/'}

  end.

index('GET',[],User) ->

...

This is a simple case, but its all I needed.

[Evan Miller]

I think this is a good idea, since the alternative is for individual
applications to have their own configuration scheme for common
access-control options, which could lead to configuration chaos. The
only risk here is adding bloat to the framework. But the benefit is
that if we take care of the most common use-cases then for many users
we can dispense with the need for an access-control proxy server. I
think that will make people's lives easier in the long-run, so I vote
yes. I'd be interested to hear other people's thoughts on this,
though.

Another benefit to moving access-control into the framework is that
you could provide a single access-denied URL for all applications in
an installation, e.g. redirect to a log-in page.

I think it would be nice to support access-control plug-ins of some
sort so that you could just drop a plug-in into a CB installation and
be able to apply its custom configuration options to a set of existing
applications. E.g. checking a single-sign-on cookie or something.
There might be some subtleties in defining the order in which
access-control options or plug-ins are invoked.

By the way there was a patch recently implementing client-certificate
checking in cb_admin, you might want to check it out and see if it
makes sense to implement in CB:

http://groups.google.com/group/chicagoboss/browse_thread/thread/cbc175598276d60f/f4fa184dbacb8ef6

[Chris Hicks]

Once I have some time I can try to dig into the internals and see if I can figure out a way to make it work. Of course since my free time is, basically, nil at this point I have no idea when that might be. Not to mention others know a lot more about the internals than I do I am sure.

I was wondering if there was an easier way of doing this than I originally thought, if it got moved into the internals. Basically, as long as there is a way to programatically call a url from within an application and have some extra parameter passed along with that call to indicate that it came from another application, it would work. Perhaps this could be a hash of a cookie put into each applications config, something like:

{restricted_access, "super secret cookie}

If that option is present in the config, that particular application will only accept requests from another CB app which shares the same cookie. As long as the config file is kept locked down then I would think it should be a fairly secure way of doing it. Maybe I'll see if I can work around this until something like this can be slipped in, if it works out that is.

Chris.

> Date: Mon, 28 May 2012 09:51:06 -0500

[Evan Miller]

To be honest I don't think it's a good idea to allow applications to
have any kind of privileged access to each other via URL redirects,
even with a secret cookie or whatever. From a security point of view
you have to start worrying about whether a programming error allows an
arbitrary redirect somewhere which would expose all of the other
application URLs in the installation, and of course whether the cookie
will get out. I guess you could implement cookie-checking logic in
your own apps, but I really don't think it belongs in the framework.
If you need an internal communication API and IP address-checking
isn't enough, I would either make it a separate application that runs
on its own port (and can't be accessed from outside) or write a quick
gen_server than handles Erlang messages.

As soon as you need applications to talk to each other I think
service-oriented architectures with network-level security is the only
way to go.

[Chris Hicks]

All good points, and in the end would probably just be as easy for an app developer to use. I stand corrected.

> Date: Tue, 29 May 2012 10:37:18 -0500