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.
Related
In Rails, Is it possible to prevent HTTP requests that come from the Browser's address bar ? And only allow navigation through links made within the app ?
I really looking for preventing a user to simply type his destination in the browser and only uses the links provided.
I know It maybe sounds silly. But I'm kind of trying to give a different UX than any regular website.
Is this approach possible? And If yes, How?
And what is the possible disadvantages or deficits that may cause?
For completeness, Yes.
The previous responder is right, this sounds like a bad idea, but it is possible. I imagine it similar to how authentication work. Set a secret value in the session on the first page, ask for it it on the second page the user reaches, if they don't match user didn't use your navigation. Refresh as quickly as needed (every page, for example).
Drawbacks? It's weird, that's not how webpages work. A clicked link (or GET request) is not different than a URL typed in the browser. What do you mean by "different UX than any regular website", the more details we have the easier we can help.
No*.
You can make it harder for a user to guess the correct URL by using obfuscation or use sessions to make the application stateful. But technically a GET request sent by clicking a link or by typing the url in the browser are identical to the server. The former is a form of security by obscurity.
The whole basically violates the core tenants of what a RESTful application does. In REST a resource should be omnipotent - requesting the same resource should provide the same response no matter how the user got there.
If you find that an action should not be able to be performed by typing the address into the browser you are most likely using the HTTP verbs wrong (using GET where you should be using POST, PUT or DELETE) or have a poor authorization system.
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.
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 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.
For a webapp written in Grails I would like to keep track of the current users account. In addition the account-name should be displayed as part of the url.
1) Keep the variable in the session
2) Pass the variable via account parameters
Currently I am experimenting with option 2 which allows me to create URL's like http://app.com/accountname/controller. The drawback is that with every URL I will have to pass the account name along as a variable. This is tedious and error prone.
Is any of the two options preferable? Are there better ways in Grails to achieve this?
Regards,
Jens
I have been using a session variable to keep track of the user's account.
Ie: session.user = userAccount;.
You could set this in your login controller.
A better way to keep track of the user is probably to set a cookie. It will be sent to the server with every request & you can easily read it. Why do you need the account name to be part of the URL? I can't think of a good reason to put the current users account in the URL. What happens when someone copy's & paste a link, and someone else follows it? Can you give some more details on what you're trying to do?