Re: Form File Uploads
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
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
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
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
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
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
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
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?
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
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
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
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
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