How does SignedCookieJar work? - ruby-on-rails

What exactly does SignedCookieJar do?
And what is the difference from that and using MessageEncryptor.encrypt_and_sign on the cookie value?

If you're ever looking for exactly what a given class does, I'd recommend consulting the source. SignedCookieJar, for instance, is in rails/actionpack/lib/action_dispatch/middleware/cookies.rb.
It would seem that a SignedCookieJar is a wrapper around the standard cookie jar, but before setting a cookie to its parent jar it will sign it with an ActiveSupport::MessageVerifier's generate method, and upon getting a cookie from the parent jar it will return nil if the verifier's verify method invalidates the signature.
The difference seems to be that MessageVerifier only signs data but leaves the original data intact, whereas MessageEncryptor will additionally encrypt the data before signing it. The Rails docs say that the use case is different in that:
[MessageEncryptor] can be used in situations similar to the MessageVerifier, but where you don’t want users to be able to determine the value of the payload.
For signed cookies, we're usually not too worried about that.

Related

ASP.NET MVC WIZARD : Passing the entry ID but keeping the app safe for all users

Guys i'have a question.
I'm currently buiding a wizard that has 5 step's until being completed.
The user starts by the first step where he generates the entry id.
From there on i start passing the id over the url like this:
host.com/{controller}/{view}/{id}
This is how my url looks like after the step1,
------- currently at view step2 passing the id=120
host.com/{controller}/step2/120
This isn't safe because as you know, anyone can change the id and affect other users's entries. Ofc, it can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Now, my question is... is there a better way to do this?
Any tips for future work?
Is what i'm doing enougth?
(begginer doubt praying for a expert awnser)
Cheers
...It can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Yes, that's true. You should start there.
Here are some other things that you could do:
You could make your entry ids Guids instead, so that a would-be hacker would never try to guess an entry id.
Because using GET for sensitive data is a bad idea, you could, as endyourif suggests, pass the entry ids with hidden fields instead.
If you are truly concerned about the user altering the ID in the URL, then you must spend the additional time adding an "isOwnedBy" like functionality.
As an additional security measure, you could pass it via a hidden variable in the form so it is at least not as easy to change as well.
Edit: I like #LeffeBrune's suggestion of encrypting the idea as well. However, I still suggest that the validation is performed on the function to ensure the user owns the object. It's just good practice.

Cookie less sessions in PHP

For one of my project's (weird) requirements, I want to use cookie less sessions. At the same time, "session.use_trans_sid" can not be turned on :(
Does anybody please let me know if is there any other way out ??
Thanks
Manish
Make a custom session manager that identifies the user based on, for example, IP address and user agent and other identifying factors (as IP+UA might not and probably will not be unique). Another (ugly) solution is to just implement the use_trans_sid functionality yourself by adding a session identifier GET parameter to every link by hand (if it's a small site) or with a hidden form (that's non-standard).
If you really want sessions without cookies, you can always put the SID in all your URLs manually. People used to do this quite a bit. :-)
The only other option is to keep the session data on the client and pass it back and forth to and from the server with each request, although technically that would be a sessionless architecture.
That means that for GETs each link has to be rewritten to include all the session variables, and for POSTs they have to be included as hidden fields.

How do I track users of my app without forcing them to register?

What is the most common strategy for tracking users with cookies without forcing them to register?
Do I create a guest account, assign a GUID, and then put that GUID value in their cookie? Is there a more generally accepted method of doing this?
Although this is a general web app question, I'm using ASP.NET MVC.
One popular solution, as you write, is to send the GUID to the user inside a cookie.
Obviusly this solution work only if the user has cookies enabled.
Please note that the contents of cookies is perfectly readable by the user who receives it.
Also the session is a good place to store temporary data.
Its duration depends on the configuration of your site and if desired, with a little 'work, it is extremely durable and can have a low impact on server memory (sessions in the db)
A guid in a cookie is one way of doing it.
If the user didn't have cookies enabled, I suppose you could do it another way which which involves creating small hashes (like bit.ly, j.mp et al) and inserting them into the url. All your routes would be populated with this hash (either created at the start of the request, or taken from the url if they already have one).
It's not exactly the cleanest of methods, but it gets around situations where the user doesn't have a cookie enabled and inserts a very small string into the url.
For example http://example.com/fG3Er/Home/Index or http://example.com/Home/Index?guestId=fG3Er where fG3Er is the unique guest id.
Alternatively, you could just append it on to the end of each url as a querystring.
Either way, I definitely favour the guid-based approach, and if the user doesn't want to use cookies on your site, you can always explain to them that their experience will be impaired. You could always find out what proportion of your users disable cookies by creating a test one, and comparing that against the number of actual hits (unless Analytics has a way of determining cookies being enabled - not sure).

What is "shva" in Gmail's URL?

What is the following portion of a Gmail URL for?
https://mail.google.com/mail/?**zx**=1efobg68r40co&**shva**=1#inbox
If you change it, nothing happens!!
I know Gmail is not an Open-Source program so we can't trace the code. But every website try to make the URL shorter so they ideally shouldn't add redundant data to the URL. At the same time they don't make any difference nor error if they change.
Edit: I know it's a parameter for a scripting language since I'm a PHP developer but as a developer I don't EVER add a useless parameter and I think it's obvious/primitive sense!
The acronym stands for "Should have valid authentication" as noted here:
http://googlesystem.blogspot.com/2010/07/gmails-shva-parameter.html
As others have noted, 1 is the default value.
If I'm remembering correctly, back when they were working on the current version of the interface, you could preview it by setting shva=2 instead of the default. That version is now the default and you can't get the old version, so shva does nothing now.
It may be used again in the future, who knows?
But every website try to make the URL shorter so they ideally shouldn't add redundant data to the URL...
This is self-evidently not true. Look at StackOverflow URLs for a perfect example. This post:
http://stackoverflow.com/questions/1692968/shva-in-gmails-url-what-is-this
could just as easily be (it works):
http://stackoverflow.com/questions/1692968
I don't think anyone worries these days about the extra couple bytes of data involved with an extra query string parameter.
Some of them saying it is" should have valid Authentication". We shall consider it OK.
But the real expansion of shva is "security host verification and authentication".
It always comes when you open Gmail.
We won't know what it 'exactly' means unless someone inside Google answers your question. But my guess would be that it has to do with security and encryption. Nothing happens when you change it because it is part of the cookie as well. So when you change it they must also compare it with what is set in the cookie.
"shva" is an acronym for "should have valid authentication". Apparently, the parameter is only included after a successful authentication.
The 1 is the default value applied to the parameter check. It's also a shorthand way for programmers to say true, like when you have successfully logged in.
The other part, #inbox, tells Gmail to load up your inbox as the first screen. You can change that to one of the other folders (or even labels you've created) to load them up.
E.g., https://mail.google.com/mail/?shva=1#sent will show your Sent folder items.
https://mail.google.com/mail/?shva=1#label/narwhals will load up your "narwhals" label.
Gmail, like many web services, serves a standard interface that will change to show only your information and data when you've logged in.
The particulars are referenced on their end through the use of an ID from the cookies or sessions generated after the login screen.

To understand a line about a login -variable in a session

What does the following line mean?
Put the boolean variable isLogin to your session such that you check the session each time your user goes to the secured site.
I would like to know how you can put a variable to a session. I know at the abstract level that
session is a semi-permanent
interactive information interchange,
also known as a dialogue, a
conversation or a meeting, between two
or more communicating devices, or
between a computer and user
I know that you can store data in a URL by separating variables by the character &.
I know at the abstract level that you need to use post orget and some read -function to check the data in the URL.
I know that cookies are files where you store data, but I have never stored data to them.
Does he mean that I should put the login -variable to the URL or to cookies?
Taking out all the context doesn't make it any easier to answer your question - actually I have to guess that you are talking about php, because it looks like you might be.
Sessions.
Sessions are a way of 'remembering' users for a limited time. Say I visit page A.php on your website first. Now, that website might define an isLoggedIn session variable for me. If a bit later I go to page B.php on your site, that site 'remembers' that variable and can tell what it' s value was.
Sessions and Cookies do have a relation, but that only matters when you want to know how sessions work. This will be important later on as you will need to know the weaknesses of sessions, but first it is important you get to know how to use them.
Before you can use session variables, you must call session_start(), to start a session - this must be called on each page that uses the session variables. Once we have we can simply access the array $_SESSION and all that's in there will be remembered with the session.
Take a look over here to get a more complete explanation and a number of examples.

Resources