I am writing a test which needs to delete cookies from a number of domains when it starts up. driver.manage().deleteAllCookies() seems to only delete cookies set by the domain you're currently on.
Is there a way to force the browser to clear all cookies?
May be this post will point you in the right direction?
http://groups.google.com/group/ruby-capybara/browse_thread/thread/7d94606d2c2abaf
https://gist.github.com/474236
You should use one profile if you want to delete all cookies. If every time selenium is creating new anonymous profile it is not possible to delete those cookies.
Related
I think this is not the first time someone askes this question. But I couldn't get a clear answer.
Is it possible to "hack" a cookie? For example, If someone is logged in, I create an 'user id' cookie, with value 'usr01301', and this is a reference to that user. If this user is loading the webpage, the website will check for cookies. If a 'user id' is available, the user will login with the account connected to the user id.
But, is someone able to write this cookie manually? Or change it to another ID? To be able to login with this cookie.
YES
Session Hijacking is a very real thing, and it is easy to exploit on any website that does not have good security systems in place. Using a username in a cookie is a really, really bad idea.
There are browser plugins that make it easy to edit cookies, but you can even do it using the developer console that ships with many browsers.
For that matter, you don't need a browser at all. wget can perform http requests with cookies from the command line.
predictable cookies are a bad idea. with that, anyone can predict cookie for any user existed on that website. and manually edit also possible ad there are lot of tools available o internet to do it autometically.
https://bugarena.com/single/Y7A7WOZ1520
I have built an ASP.Net MVC site using Forms Authentication for a client.
Recently, they have requested that an authenticated user be restricted to a single browser session. That is, if the user raises a new browser instance, or opens a new tab on the original browser window, that he/she be logged out of the original. They insist on the added security.
Does anyone know how I might approach this? Thanks in advance.
Personally, I would push back and ask exactly what security this is bringing. Maintaining state like this counter to web architecture and is only going to bring you and your users grief.
Here is what I would do if presented with this problem:
Store the username of the user in your database (i.e. LoggedOn table).
When a user logs on, check to see if their username is already present in the LoggedOn table.
If the user isn't already logged on, insert a row into the table with the username and the current time; otherwise present the user with a message informing them that they can only log into the system from one device at a time.
Include logic to expire and delete the rows in the table if a user's session expires or if the user logs out.
First a disclaimer: I'm no expert in web programming.
Perhaps you might try a system where every user interaction requires the submission of a random value that's been generated for that page (much like what's used for CSRF protection.) That key could be kept under the user's session information on the server, and if a page is ever requested without the correct key as a URL parameter, the session is invalidated. The URL from one browser won't work in another, either, since once a URL is gone to, the user's session key has changed. The only way for a user to transfer a session between tabs would be to copy the URL of an unclicked link and paste it in a new tab's address bar. Switching browsers would be even more complex assuming that ASP.Net uses a session cookie: the user would have to transfer the cookie from one browser to another. Going back would also fail, as all the links on the previous page, and the URL for the page, would carry an incorrect session key.
Also, for reference, I believe the US Gov't TreasuryDirect site works in the way you've described, though I've never looked at how they manage it.
Thanks, people for the suggestions. Each had strong merits, however I had to take a hybrid approach. I found an incredibly simple suggestion from this post.
I implemented table of active users as Karl suggested as well. This will give the client the ability of deactivating the user on demand.
Thanks again.
Think of it as one active view at a time instead of one browser or tab. Or convince the customer to view it this way.
You can always issue a unique cookie for the browser session (ASP.NET Session) and allow communication to the latest cookie issued effectively making only one session active at a time, and therefore rendering other open sessions (browsers, tabs, etc) useless with the app by disallowing them communication any longer or serving up an error page for them. To do so you have to recognize who the user is and authenticate them against your app. This is half the puzzle and will force the user down to use your app in only a single browser at a time on their machine.
The other part of the problem is to pare down the windows and tabs that are part of the same browsing session of that browser, to allow only one view to be active at a time. To do so you can issue a unique sequential ID to the viewstate of each page for postback to the server to uniquely identify that page apart from other pages sharing the same session state (whether that page be in a browser tab, a frame or new window, etc). Or a code of your choice that's traceable. You then know which page is posting back within the session and can disallow others or deactivate previous ones by, again, shutdown down communication in some manner or serving up an error page, etc.
A new browser instance or a new tab may or may not be part of the same browsing session depending on how the browser is configured. I believe, for example, IE provides a setting that allows the behaviour to be set of whether a tab opens in a new process or session or shares the session. You won't necessarily get expected consistency across browsers to rely on for this feature, therefore you need to take programming steps to reign it in, like those described above.
You can additional steps like disallowing the user to be connected from a different IP# at the same time.
In a nutshell, I'm trying to figure out how to programmatically enable and disable the redirection for mobile phones, based on a session value, on a per request basis (not statically for everyone).
Here's the back story:
I'm currently using 51Degrees in my ASP.NET application to redirect requests to the mobile version of the site. I would like to add a feature where users can enable and disable this redirection from a "Settings" page. The setting will be different for each user, and so far every setting I've found to disable 51Degrees is static. This makes it difficult to disable it for a subset of users.
One semi-solution I had was to set firstRequestOnly="true" and reverse the redirect if it wasn't supposed to happen. Although firstRequestOnly="true" has caused a number of other headaches (unrelated) so I would like to keep it at firstRequestOnly="false" and simply enable/disable the redirection based on a session value per request, or per user. The problem is that I can't figure out a clean way to do this.
Set the cookie in the page prerender event based on the setting your user has choosen in their profile. You would need to have firstRequestOnly set to true. If the user does not want redirection it should have a very long expiry time, if they do then set a short expiry time.
I ended up just downloading the source code and adding in an option to opt-out of the redirect if a certain session field was present and set to true. This allowed me to set that session value from my code depending on what the user had setup in the settings section. Not the best solution since it's going to be more difficult to upgrade 51Degrees down the road, but it works.
I have a like/dislike buttons and I put them in an update panel to be able to update the counter without refresh the page, the problem that the user can click like/dislike button several times and the counter will be changes
I want to allow user to click the button once I think I may use cookie but I didn't used it before so if anyone can help me doing that I will be thankful
also if there is any other solution that may be better please let me know
Thanks in Advance
If you want to use cookies, you can look at this page (older version) or this page (newer version).
You haven't described what kind of website you are creating, but if you have a user registration/login mechanism, you could just save information that a specific user clicked the like button in your database.
If logging in is not acceptable, you can try to identify your users by their IP addresses, as Adam suggested. You can do this by using:
String remoteAddress = HttpContext.Current.Request.UserHostAddress;
or
String remoteAddress = HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"];
Either way I think it would be best to use cookies combined with another method, because you can then check the cookie first. If it exists on a user's computer, you know she/he has already voted. If the cookie is not there, you can query a database for the saved information about the user (identified by IP or login mechanism). This way you can make less queries to the database, which should be good for your application's performance :).
Instead of using cookies you can track via IP address.
I know IP addresses can change over time so you could use this with cookies but cookies can also be cleared so nothing will be 100%.
When a user clicks like or dislike, store their IP address with the record of the like.
Place code to stop another like or dislike counting if they already have done so.
Then on your update remove the like or dislike button and just show the count.
This is what I use for my application. I also have a Facebook app, in which I use their Facebook user Id which is much harder to fake.
Either way I think IP address is the best way to detect and stop someone from doing it twice.
I've just come across an interesting fact, apparently a website can have up to 20 seperate cookies.
Ok - fair enough.
But why on earth would you store more than say "UserID", and why would you possibly need 20 cookies?
If you offer the user a way to customize your site you need to store their settings somewhere.
You might need cookies for:
user settings
the session id
the contents of a shopping basket
the last item viewed
the user login
Some that I can think of:
persistent login cookie
session cookie
user-independent settings
user-tracking-cookie
It's a choice. If you don't need 20 cookies, it doesn't mean somebody else won't.
Agree with PiedPiper and thejh. If you are storing user info and customizing the behaviour of your site based on users actions, then very soon you will run out of storage limit of single cookie.
A site can have multiple pages, and a lot of those pages may have some information that might in turn be stored in cookies. It is ironic that you ask WHY you may want to use a lot of cookies where as I have seen a lot of people complaining why ONLY 20!!!
It is a good practice to ensure that you DO NOT create a lot of cookies, simply because IE has 20 cookie limit. Other browsers may have more [or less]!