similar to: Quickie: URL Shortener''s, some code.

You''ll need to install the ''openid'' gem for this, and require it in your camping app: class Login < R ''/login'' def get this_url = ''http:'' + URL(''/login'').to_s unless input.finish.to_s == ''1'' # start doing the auth here begin

Hey Judofyr! Fix this! When someone sets a cookie using @cookies.something = ''data'' it should be set with the path going to the camping app''s root, not with no path, otherwise only that controller with the same parameters will ever see the cookie again! Please change this code: > @cookies.each do |k, v| > @response.set_cookie(k, v) if o[k] != v > end

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

We''ve just come across an issue for consideration. I am avoiding some words which would allow people to find this message in an internet search who have questionable intentions, but wish to communicate a strong sense of caution. Consider someone who adds extra methods to their controller which they use in their main get/post methods to do things or to get secret data. Consider

So it took me ages to figure out how to get cookies set in my app, and here was the problem. I''m using camping''s built in CGI support, and with that you can have something like domain.com/blah/app.rb and that will go to your / route, which is okay, except that the path the cookies are set with is domain.com/blah/app.rb/ So if you try to use that url, none of your

I''ve just sent a pull-request to _why with my changes[1] and here is some things that I think needs to be done before a (possible) release: * The cookie session is named Camping::Session and is placed in camping/session.rb. Maybe this should be called Camping::CookieSession or??? * The ActiveRecord session is named Camping::ARSession and is placed in camping/ar/session.rb. Maybe it

It looks like everyone has tried to fix the cookies lately, and no-one managed to get it 100% correctly. The current implementation doesn''t set the path correctly, and you can''t use @cookies in a #service-overload. Qwzybug''s patch fixed only the sessions. Jenna''s patch won''t allow to set complex cookies (@cookies.key = {:path => "/path",

A few of you sounded interested in using it. I haven''t explicitly put a software license on it, so I guess it''s not technically FOSS yet. What licenses are good? BSD? Public Domain? ? Jenna -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120502/96b87580/attachment.html>

I was having some issue getting the class variables in Camping::Session to work with some old apps, so I''ve changed @@state_secret to a method. module Blog include Camping::Session def state_secret; "kxxxx" end end Also, merged some of zimbatm''s patches. And trying to revive the Junebug wiki <http://github.com/why/junebug> since it''s still

Good day, does anyone here have a clue on how to make use of the NoSQL database "Riak" with Camping? I am building my website and Riak seems like pretty much the ultimate database! This would probably ruin every little feature in ActiveRecord, I don''t think I''d be able to do any has_many''s or belongs_to but I''d LOVE to be proven wrong. As far as

on like 257 of camping-unabridged.rb: > # "http" + URL("/view/12") #=> "http://test.ing/blog/view/12" is wrong, the string should be "http:", or the result will be "http// test.ing/blob/view/12" ? Jenna ?Who Isn''t a? Fox

Isn't the whole concept of DOI basically link-shortening/redirecting? For example, this link https://doi.org/10.2134/agronj2016.07.0395 redirects to https://acsess.onlinelibrary.wiley.com/doi/abs/10.2134/agronj2016.07.0395 As a side note, I got so fed up with CRAN check complaints about (perfectly valid) re-directs that I refuse to use the \url{} tag anymore. Kevin On Thu, Sep 17, 2020 at

I don't have an opinion on the URL shorteners, but how about the original question? Redirection can be extremely useful in general. Shortening URLs is only one of its possible applications. FWIW, CRAN uses (303) redirect itself, e.g., https://cran.r-project.org/package=MASS is redirected to https://cran.r-project.org/web/packages/MASS/index.html Should these "canonical" CRAN links be

Me too. I have changed some valid URLs in \url{} to \verb{} just to avoid these check NOTEs. I do appreciate the check for the validity of URLs in packages, especially those dead links (404), but discouraging URLs with status code other than 200 (such as 301) feels like overdoing the job. After I "hide" links from R CMD check with \verb{} , it will be hard to know if these links are

Dear all, the new CRAN URL checks flag HTTP 301 redirects. While I understand the intent, I think this is unfortunate, because several URL shortener services use 301 redirects, and often a shorter URL is actually better in a manual page than a longer one that can be several lines long in the console and also potentially truncated in the PDF manual. Some example shorteners that are flagged: >

I can't comment for CRAN, but generally, shorteners are considered security risk so regardless of the 301 handling I think flagging those is a good idea. Also I think it is particularly bad to use them in manuals because it hides the target so the user has no idea what hey will get. Cheers, Simon > On Sep 17, 2020, at 5:35 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: >

Right, I am sorry, I did not realize the security aspect here. I guess I unconsciously treated CRAN package authors as a trusted source. Thanks for the correction and clarification, and to CRAN for implementing these checks. :) G. On Wed, Sep 16, 2020 at 10:50 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > On 16/09/2020 4:51 p.m., Simon Urbanek wrote: > > I

On 16/09/2020 4:51 p.m., Simon Urbanek wrote: > I can't comment for CRAN, but generally, shorteners are considered security risk so regardless of the 301 handling I think flagging those is a good idea. Also I think it is particularly bad to use them in manuals because it hides the target so the user has no idea what hey will get. I agree, and we do have \href{}{} in Rd files and similar in

{} || || ~~~~~~~~~~~~~~~ <= _whycake ~ Camping 2.1 ~ ~~~~~~~~~~~~~~~ I''m pleased to announce another release of Camping, the microframework. This time we''ve focused on improving the 1.9 support, adding (builtin) support for more template engines, refreshing the homepage and just general bug fixes. gem install camping Home:

Well, this is more of an apache question, but... I''m running a nice little ''cluster'' of camping apps and I''ve recently started proxying them through apache with mod_proxy, since I found I was forwarding a lot of ports via ssh otherwise. But anyway, enough of that. One of the apps I use to view logs from IRC (with formatting and highlighting!). But