Session ID being shared across multiple tabs in IE 7, Firefox
-
The problem only occurs for a small group of users which represent a miniscule percentage of 10,000s of users with a potental of 100,000s of users. The users are seasonal, so we're not talking concurrent users but the number of distinct users each year. And so due to both deployment issues and staff limitations, supporting 2 codebases (web and desktop) is not really an option.
Mark's blog: developMENTALmadness.blogspot.com
-
Then I would prefer restructuring the data to eliminate the shared variables rather than trying to hack the session mechanism. Good luck
apart from maintaining all the variables in the url I don't see how that would be done. Lets say, I have two variables named entityid and year which get set after the user searches for an entity and selects it from the results of that search and the user selects a year. Then the user opens a new window (same session) and searches again, but selects a different entity or a different year and navigates to the same data entry page. Now when the user navigates back to the first window his session data is invalid, but he proceeds to enter new data into the window. He has just entered new data into the wrong entity and year. This is a simplified example but demonstrates my point. How else, other than through urls, would you accomplish this?
Mark's blog: developMENTALmadness.blogspot.com
-
apart from maintaining all the variables in the url I don't see how that would be done. Lets say, I have two variables named entityid and year which get set after the user searches for an entity and selects it from the results of that search and the user selects a year. Then the user opens a new window (same session) and searches again, but selects a different entity or a different year and navigates to the same data entry page. Now when the user navigates back to the first window his session data is invalid, but he proceeds to enter new data into the window. He has just entered new data into the wrong entity and year. This is a simplified example but demonstrates my point. How else, other than through urls, would you accomplish this?
Mark's blog: developMENTALmadness.blogspot.com
Mark J. Miller wrote:
How else, other than through urls, would you accomplish this?
Well hidden fields are obvious so there must be more to your question than that. Also that does nothing to eliminate all the complexity you described in your first post to handle the multiple window problem. Complexity that would not exist in a Desktop solution. Complexity in the software to make deployment easier. It's a trade off that's all I am saying. One that personally I feel is vastly overused and certainly is here where I work. By the way complexity of the software is not the only detriment normally associated with Web Applications being misused as desktop applications. The user experience frequently suffers greatly as well.
All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.
Arthur Schopenhauer - German philosopher (1788 - 1860)
-
apart from maintaining all the variables in the url I don't see how that would be done. Lets say, I have two variables named entityid and year which get set after the user searches for an entity and selects it from the results of that search and the user selects a year. Then the user opens a new window (same session) and searches again, but selects a different entity or a different year and navigates to the same data entry page. Now when the user navigates back to the first window his session data is invalid, but he proceeds to enter new data into the window. He has just entered new data into the wrong entity and year. This is a simplified example but demonstrates my point. How else, other than through urls, would you accomplish this?
Mark's blog: developMENTALmadness.blogspot.com
-
Mark J. Miller wrote:
How else, other than through urls, would you accomplish this?
Well hidden fields are obvious so there must be more to your question than that. Also that does nothing to eliminate all the complexity you described in your first post to handle the multiple window problem. Complexity that would not exist in a Desktop solution. Complexity in the software to make deployment easier. It's a trade off that's all I am saying. One that personally I feel is vastly overused and certainly is here where I work. By the way complexity of the software is not the only detriment normally associated with Web Applications being misused as desktop applications. The user experience frequently suffers greatly as well.
All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.
Arthur Schopenhauer - German philosopher (1788 - 1860)
If I understand you correctly, your view is that the web adds unnecessary complexities to an application which degrades the user experience. You also believe that companies are too quick to put applications out on the web and in many cases no thought is given to wither or not the web is even a good solution or it will cause more problems than it will solve. In other words the web becomes the hammer which is used when the problem isn't even a nail. If that's what you're saying, I agree. The web is definately overused. Plus, the web introduces complexities like an increased attack surface and the cost of putting all the buisiness logic on the server. I also agree that a desktop application will eliminate the problem in question because you can control the windows opened by the user and multiple instances of the same application wouldn't share volitle state data. However, I disagree that my solution is overly complex. I gave a lot of detail to give the poster an idea of how it could be implemented because I wasn't including the source code. In reality the solution simply wraps an xml schema and monitors a single element for changes to its children. When a change happens a new Guid is generated. On the web side the consumer subscribes to an event which tells it when to update the client's cookie. The public key is included in any urls and each request is monitored to make sure the key is included. It behaves like session state and is consumed the same way but doesn't touch the built-in session mechanism. And just because I'm bypassing built-in session state and rolling my own doesn't make this a hack. It's true most applications don't require this kind of mechanism, but that requirement alone doesn't automatically mean that it should be moved to the desktop. A web application is a valid solution to a business need and multiple browser windows (or tabs) which share a single cookie is a reality of the web. I am simply presenting a solution to that condition when it becomes a problem for some applications.
Mark's blog: developMENTALmadness.blogspot.com
-
I had not see the specific page, but I am aware of cookieless sessions. But first, the original poster expressed a valid concern that cookieless sessions can easily be hijacked. There is a link in on the page you referenced which talks specifically about session hijacking and the solution requires cookies. Secondly, cookieless sessions still don't solve the problem in the subject of the post. If a user opens a new browser window using CTRL+N, the browser menu or the shortcut menu (or the corresponding tab commands) the url will contain the same session id and you have the exact same problem. If users always used the quick launch toolbar, the start menu (or whatever the linux or mac commands are) then cookieless sessions would be a good solution in this case. But you can't be sure they will and in fact most users will not because it's quicker to use the browser commands instead of opening a new browser which opens to the user's home page instead of your site. My solution takes all of this into account. Because you can't control the number of browsers a user will use to navigate your site/application you can't control the url in each of those browsers. So again, while I agree with your premise that many applications should not be on the web, I maintain that the original post is a valid problem on the web and in some cases requires a solution like the one I am proposing.
Mark's blog: developMENTALmadness.blogspot.com
-
If I understand you correctly, your view is that the web adds unnecessary complexities to an application which degrades the user experience. You also believe that companies are too quick to put applications out on the web and in many cases no thought is given to wither or not the web is even a good solution or it will cause more problems than it will solve. In other words the web becomes the hammer which is used when the problem isn't even a nail. If that's what you're saying, I agree. The web is definately overused. Plus, the web introduces complexities like an increased attack surface and the cost of putting all the buisiness logic on the server. I also agree that a desktop application will eliminate the problem in question because you can control the windows opened by the user and multiple instances of the same application wouldn't share volitle state data. However, I disagree that my solution is overly complex. I gave a lot of detail to give the poster an idea of how it could be implemented because I wasn't including the source code. In reality the solution simply wraps an xml schema and monitors a single element for changes to its children. When a change happens a new Guid is generated. On the web side the consumer subscribes to an event which tells it when to update the client's cookie. The public key is included in any urls and each request is monitored to make sure the key is included. It behaves like session state and is consumed the same way but doesn't touch the built-in session mechanism. And just because I'm bypassing built-in session state and rolling my own doesn't make this a hack. It's true most applications don't require this kind of mechanism, but that requirement alone doesn't automatically mean that it should be moved to the desktop. A web application is a valid solution to a business need and multiple browser windows (or tabs) which share a single cookie is a reality of the web. I am simply presenting a solution to that condition when it becomes a problem for some applications.
Mark's blog: developMENTALmadness.blogspot.com
-
Mark J. Miller wrote:
However, I disagree that my solution is overly complex.
Yeah that's not what I meant. Just what you said before, having to do any of that regardless of how well it's done adds complexity.
Ok, I can agree with that.
Mark's blog: developMENTALmadness.blogspot.com
-
I had not see the specific page, but I am aware of cookieless sessions. But first, the original poster expressed a valid concern that cookieless sessions can easily be hijacked. There is a link in on the page you referenced which talks specifically about session hijacking and the solution requires cookies. Secondly, cookieless sessions still don't solve the problem in the subject of the post. If a user opens a new browser window using CTRL+N, the browser menu or the shortcut menu (or the corresponding tab commands) the url will contain the same session id and you have the exact same problem. If users always used the quick launch toolbar, the start menu (or whatever the linux or mac commands are) then cookieless sessions would be a good solution in this case. But you can't be sure they will and in fact most users will not because it's quicker to use the browser commands instead of opening a new browser which opens to the user's home page instead of your site. My solution takes all of this into account. Because you can't control the number of browsers a user will use to navigate your site/application you can't control the url in each of those browsers. So again, while I agree with your premise that many applications should not be on the web, I maintain that the original post is a valid problem on the web and in some cases requires a solution like the one I am proposing.
Mark's blog: developMENTALmadness.blogspot.com
Mark J. Miller wrote:
I maintain that the original post is a valid problem on the web and in some cases requires a solution like the one I am proposing.
Hopefully you understand that was never questioning your implementation, only the choice for the application to be browser based. Obviously I can't know since my entire point is based on complete analysis of any project which I of course can't do. That is why none of my language indicated any absolutes for your project. It seems we are in agreement from what I can tell. :)
-
Mark J. Miller wrote:
I maintain that the original post is a valid problem on the web and in some cases requires a solution like the one I am proposing.
Hopefully you understand that was never questioning your implementation, only the choice for the application to be browser based. Obviously I can't know since my entire point is based on complete analysis of any project which I of course can't do. That is why none of my language indicated any absolutes for your project. It seems we are in agreement from what I can tell. :)
I wasn't completely sure at first, glad you cleared that up :) . And you're right, it is an important question to be asked. Sometimes I tend to propose a solution to answer a question w/o questioning wither the asker is even heading down the right path in the first place. It probably stems from a desire to be helpful (which it isn't always). Also from frustration when I have posted questions (never on CP) which the only answer I get is "are you sure?", followed by a defining silence when I explain that yes I am sure and I need help.
Mark's blog: developMENTALmadness.blogspot.com