Re: Form File Uploads

2008-08-27 Thread Bluebie, Jenna
If you're using Camping 2.0 stuff off github, file uploads work  
exactly as they do in regular rack, so search around for rack upload  
examples. :)


In camping 1.5, it works quite similarly, like this:

input.fieldname.tempfile.length #= how many bytes long it is
input.fieldname[:type] #= mimetype of upload
input.fieldname.tempfile.read #= gets you the files contents...  
tempfile will be some kind of an IO object.


I think you can do .filename also, but I don't use it in my projects.

Rack is similar, though at least in builds before Mash got in on the  
action, the syntax was a bit different.

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Troubleshooting: Camping 2.0 on CGI on a shared host

2008-07-14 Thread Bluebie, Jenna

Could you show us the .htaccess please? :)
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Troubleshooting: Camping 2.0 on CGI on a shared host

2008-07-14 Thread Bluebie, Jenna
Also, is it possible that you could simply rename dispatch.cgi to  
something like 'appname' and use htaccess to grant that file cgi  
execution type permissions? Or does this need to be on the root of a  
domain?

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Troubleshooting: Camping 2.0 on CGI on a shared host

2008-07-14 Thread Bluebie, Jenna

can you please try adding to htaccess SetEnv SCRIPT_NAME /path/to/app

Assuming your dispatch is in /path/to/app/dispatch.cgi

Let us know what happens!
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Troubleshooting: Camping 2.0 on CGI on a shared host

2008-07-14 Thread Bluebie, Jenna

No wait, this is even better, at the end of your RewriteRule, put:

[env=SCRIPT_NAME:/path/to/app]

Let us know what happens!
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Troubleshooting: Camping 2.0 on CGI on a shared host

2008-07-14 Thread Bluebie, Jenna
I really do think we should build in the SCRIPT_URL || SCRIPT_NAME  
thingo. This is going to be a relatively common situation. Totally  
worth the bytes.

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Troubleshooting: Camping 2.0 on CGI on a shared host

2008-07-14 Thread Bluebie, Jenna
We are talking about cgi here, not fast cgi. Specifically CGI's  
interactions with mod_rewrite in apache.

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Messy Cookies

2008-06-06 Thread Bluebie, Jenna
Judofyr: This isn't a question to ask _why. It simply cannot be done.  
Stealing cookies is not the same thing as XSS, and locking cookies to  
an IP address will not stop XSS at all. Locking cookies to an IP  
address (as I wrote in my git commit where I removed it) will lock out  
AOL users, and surely many others on large NAT based networks. We  
aren't just talking getting logged out occasionally. Every single  
request from an AOL user comes from a seemingly random IP address,  
often from a different continent to where the user is. This is because  
AOL user's don't have their own internet IP address. The network is a  
giant nat, but it's a nat with several outgoing IP's, and every time a  
connection is made, it's sent through a different IP.


In a world where IPv6 still hasn't gained serious traction and the  
IPv4 address space continues to shrink, this practice is only becoming  
more and more common. In some countries, they only have 2-5 IP's to  
NAT the whole country through.


To understand why we can't fix XSS in the cookies handler you have to  
understand what XSS is. Imagine a bank, who has a camping app for  
internet banking. Imagine they have a /login controller, and a / 
transfer_monies controller. XSS is when a bad person creates a webpage  
with a tag in it capable of loading remote resources, like img, and  
sets the src attribute to http://mybank.com/transfer_monies?to=888422243name=Hahahahaha


Then they direct the user to this page, which could be on myspace or  
anywhere else html embedding is allowed, while the target is logged in  
to their banking website. When their browser reaches the page, and  
parses the img, it throws that get request on to the queue, and when  
it gets around to it, it goes right ahead and loads that address with  
a get request with all the users cookies in tact. This can't be worked  
around by requiring important things to be done with the 'post' method  
either as it is incredibly easy to make an invisible form that  
automatically submits as soon as it is parsed.


The one attack binding cookies to the user's IP address prevents (in  
countries and ISP's where each user has their own IP address, and  
their ISP's don't allow other user's to request a specific IP from the  
DHCP server's and get it if it is available now) is someone who  
inserts a script or a java applet or flash player in to the page,  
and then puts scripting in the script, applet, or flash, to read the  
value of document.cookie, url encode it, and send it to a remote  
server the attacker controls... or even just to a guestbook or  
something. The lesson here is don't let your user's embed nasty html  
code if your site has valuable stuff in it, or if you have admin  
accounts that can do damage if stolen.


One way to put a stop to XSS attacks is to require important requests  
to have a token on the end, something only the server knows. The token  
is added to all the links that change some state on the server, and  
all of those controllers have to check it and instantly redirect the  
user back to a page where there is no token. If they don't redirect  
back, the user is left on a url with a token in it and they are then  
vulnerable to social engineering.


I've put up a simple implementation of this here: 
http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions

But I'm sure you can imagine why this process cannot be automated.  
Camping can't know which controllers are important and which aren't,  
and the user still has to consciously make them redirect back to some  
place. Using that little script, the attacker can't figure out the url  
to put in their img and so they can't make a valid request. One  
thing that would also help against XSS would be to dump all requests  
that have a referrer from some place else, but then.. nobody would be  
able to get to your app from a link on some website anymore.


All these things are far beyond the scope of Session anyway. I feel  
very strongly that if you make the cookies locked down to an IP  
address then you are making camping incompatible with the internet.


On the plus side: Yay! We have working sessions! ^_^

Does the stuff I changed now work? Can you safely use @body, @headers,  
@cookies from anywhere inside a service?


—
Jenna

On 07/06/2008, at 6:06 AM, Devin Chalmers wrote:


On Fri, Jun 6, 2008 at 6:07 AM, Magnus Holm [EMAIL PROTECTED] wrote:
It looks like everyone has tried to fix the cookies lately, and no- 
one managed

to get it 100% correctly...

Thanks for the code, that seems to work really well and prettily. I  
admit that, though I love writing apps in it, I am very new to  
hacking on the dark underbelly of Camping. (Me, I just wanted to get  
sessions to work in the Junebug wiki for a Ruby class I'm teaching  
some friends.)


Your new patch makes sense to me. I'd be interested to hear a  
discussion of why the Bluebie version didn't work, because I thought  
that made sense too. :)


Re: Camping 2.0 - What's left?

2008-05-25 Thread Bluebie, Jenna
I forgot to mention though, the signing just stops users from changing  
the session data without the server knowing, it doesn't stop them from  
reading it. Any data in the session when using the cookie sessions  
store only needs to be base64 decoded and unmarshaled with ruby to  
find out what's inside. As far as i'm concerned, any app that's  
keeping secrets from me about me is not the kind of app I want to be  
using anyway.



On 25/05/2008, at 1:43 PM, _why wrote:


On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:

* The cookie session is named Camping::Session and is placed in
camping/session.rb. Maybe this should be called  
Camping::CookieSession or???


You know, these cookie sessions seem like they could be a problem.
A lot of sessions would contain just the hash and the user name.
So, spoof the user name and you're in, you know?

_why
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Sample Code, quick simple openid auth

2008-05-20 Thread Bluebie, Jenna
Sure, but if you're building an app that keeps secrets about me from  
me, I'd rather not use it, thank you.



On 20/05/2008, at 6:01 PM, Magnus Holm wrote:

Everyone can read their session, though. I can post an example which  
encrypts everything (don't expect it to be super-fast).


On Tue, May 20, 2008 at 7:30 AM, Bluebie, Jenna [EMAIL PROTECTED] 
 wrote:

Also, here's a simple way to stop XSS dead! 
http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions

—
Jenna is hoping all this will earn here some oats! Fox

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list



--
Magnus Holm ___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Setting cookies in service overloader thingo

2008-05-17 Thread Bluebie, Jenna
I'm implementing a simpler version of the Cookie Session Store in  
Rails 2.0. If you know what that is, skip the next paragraph.


A cookie session store stores the session data inside cookies, on the  
client, and signs them using a secret string, hashed together. The  
user can decode the cookie easily if they know much about computers  
and see what's inside, but they can't alter it because they can't  
generate the needed hash to sign it, and the server will ignore all  
cookie session data that isn't signed right. It's neat, you don't need  
a database, no file system clutter, and I think it feels really just a  
lot more natural this way.


Trouble is, I'm trying to make it work as a drop in replacement for  
the camping sessions mixin so people can 'upgrade' in either direction  
easily, consider this code however...



def service(*a)
  if @cookies.identity
blob, secure_hash = @cookies.identity.to_s.split(':')
blob = Base64.decode64(blob)
data = Marshal.restore(blob)
data = {} unless secure_blob_hasher(blob) == secure_hash
  else
blob = ''
data = {}
  end

  app = self.class.name.gsub(/^(\w+)::.+$/, '\1')
  @state = (data[app] ||= Camping::H[])
  hash_before = blob.hash
  return super(*a)
ensure
  if data
data[app] = @state
blob = Marshal.dump(data)
unless hash_before == blob.hash
  secure_hash = secure_blob_hasher(blob)
  @cookies.identity = Base64.encode64(blob).strip + ':' +  
secure_hash

end
  end
end


and there's quite a problem, check out that line, return super(*a),  
and look at the camping source, and soon enough one realises the  
reason this doesn't work at all is that the code inside the super is  
the code converting @cookies in to the Set-Cookie http header, so it's  
too late to set a cookie by the time the ensure block runs and tries  
to save the session.


What should I do? It feels dirty to copy code out of camping.rb that  
serializes the cookies, in effect making it do that job twice every  
time the session data and any other cookie data changes (which  
wouldn't be a big deal for my app, but still seems nasty). Anyone got  
a better idea?



—
Jenna “Where's my oats” Fox___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Setting cookies in service overloader thingo

2008-05-17 Thread Bluebie, Jenna
I haven't read through all of camping yet, I only started playing with  
it seriously a few days ago, so I don't know where might be a better  
place for it. Maybe whatever it is which calls service could do the  
cookies.


it would be nice if there was a way to set cookies long term too,  
though it isn't really important and for my app, the only place I'd be  
using it is to duplicate the form filling out functionality for my  
openid login box that all modern browser's already provide.


It is really refreshing for cookies to be so simple. I have very mixed  
feelings about making them 'complete'.


If more complete cookie support were added, that would surely include  
the setting of expiry, this opens up another big change in that many  
apps set the same cookie over and over even though nothing has changed  
because they want the expiry to always be, for example, one week after  
the last page the user loaded. The framework currently doesn't make  
allowances for setting the same cookie over and over when no data has  
changed either.


Maybe it's best to stick with simple cookie support. If people really  
need much more I don't feel it unfair for them to need to hack it in  
themselves or move up to rails and the likes.


—
Jenna ”Where's my equestrian hat?” Fox

On 18/05/2008, at 2:41 AM, zimbatm wrote:


Nice catch,

cookies support never really felt complete to me. Maybe we should put
it in a different module ?

Cheers,
 zimbatm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Camping-Omnibus Doesn't Work With Ruby v1.8.6

2008-05-17 Thread Bluebie, Jenna
Yeah, and because ruby 1.8.6 comes with Mac OS X Leopard, that's  
probably scaring plenty of people (me included!)


—
Jenna “The Omnibus” Fox
On 18/05/2008, at 2:40 AM, zimbatm wrote:

Ok noted, it should probably be fixed once camping is released on  
rubyforge


2008/5/10 Trevor Johns [EMAIL PROTECTED]:
I've noticed that the copy of Mongrel installed by the camping- 
omnibus gem
doesn't work with Ruby 1.8.6. Or to be more specific,  
cgi_multipart_eof_fix

(which Mongrel is dependent upon) doesn't work:


$ sudo gem install mongrel --source http://code.whytheluckystiff.net

ERROR:  Error installing mongrel:
  cgi_multipart_eof_fix requires Ruby version = 1.8.5


It looks like the copy of Mongrel mirrored on  
code.whytheluckystiff.net is

v1.0.1. The latest public release is v1.1.4.

Working around this is easy (just download the component parts  
individually
from gems.rubyforge.org), but it might scare away some newbies who  
are
following the directions on the wiki. Time to update the Gems  
hosted on

code.whytheluckystiff.net?

On a related note, how come camping-omnibus doesn't exist on
gems.rubyforge.org?

--
Trevor Johns
http://tjohns.net

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list