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] #=
Could you show us the .htaccess please? :)
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
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
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
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
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
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
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
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
, 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
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
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,
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
13 matches
Mail list logo
