|
Hi All,
When an application is being accessed at the same time using multiple tabs in IE7 the session id is being shared and this leads to some problems. Let us say when i opened the application in the first tab the session id is abcdsa1234.... then i opened the same application in the second the session id is same i.e. abcdsa1234..... This leads to several issues.
A solution to this would be making the sessions cookie-less, this way when accessing the same application using multiple tabs different session ids would be created however the session id values are shown in the URL and this for sure is a security threat!
Are there any other ways to handle session ids when accessing the application using multiple tabs or multiple windows??
gauthee
|
|
|
|
|
I just recently have been working on a solution for this which combines both cookies and url session id. My solution focuses on preventing corruption of session data when users open multiple tabs/windows and are browsing to the different pages in the same application which use common variables. I have to admit that I did not consider wither it was secure to have any kind of session key w/in the url.
- All session data is stored as xml in a database on the server. The url and cookies only store the keys to retrieve the data. The key for the data is a session id and a ticket, both are guids.
- The session id is concatenated with the ticket, encrypted with a protected, private key and stored in the client's cookie. The ticket is then used as the key to store and retrieve the encrypted data to/from the client's cookie.
- The ticket is publicly displayed in the url and maintained in all application links, urls
- When session data which is relative to the users location (context) changes a new ticket is generated and the database is updated. Then the session id and new ticket are again encrypted together and stored in the client's cookie. The response from the web server (resulting html page) will contain links/urls with the new ticket.
- If the user tries to change tabs/windows and browse using the expired ticket it will not be found in the database and they will recieve a 'SessionExpired' error and can either be asked to login again to obtain a new session id or redirected to the home page with the context data cleared out.
Some of this is flexible and could change to meet the business needs of the application. For example, the logic could be changed to prevent the 'SessionExpired' error so the user can continue using both windows w/o logging in again or being redirected. For my purposes this involved extra work and wasn't necessary so I didn't write it this way, but it could be done.
I'm curious for feedback from others on this, so since you were looking for something like this I'm interested in what you think.
|
|
|
|
|
Mark J. Miller wrote: preventing corruption of session data when users open multiple tabs/windows and are browsing to the different pages in the same application which use common variables.
If it's possible restructure the data so that this problem does not exist.
If that is not possible then it might indicate that a Browser based solution for that application is inferior to a Desktop application.
|
|
|
|
|
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.
|
|
|
|
|
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 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 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.
|
|
|
|
|
Editing posts seems to broken the past few days 
It's likely you have seen this[^] but just in case.
|
|
|
|
|
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 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.
|
|
|
|
|
I have an application (VB.Net2) which takes an image (JPEG) file and resizes it.
I have tested this application by putting it into a local version of my website (which also contains local copy of my image library) hosted on my PC. The images shown on the web pages are crisp and clear.
But when I put this same version of the website (including image library) onto my remote webserver, the images shown on the served web pages are markedly pixallated (even in areas that are normally flat colour). I have downloaed the images from the image library to check them on my PC and they are fine.
Why should the website produce crsip/clear images when hosted locally yet grainy/pixallated images when hosted on a remote web server?
Thanks in anticipation.
Chris
|
|
|
|
|
Greetings,
I'm looking for some information on how to display images in ASP.
My criteria is to use drop down menues on the webpage which will be the paramaters
for a sql stored procedure.
The thing I really can't find is, how to store the image on a file location, but have
the "link" to the photo in the sql table.
Example: I have two drop down menus. A user might pick "family" from the first drop down,
and "vacations" from the second. When they hit an ok button, it would run the sql stored
procedure with the parmaters family & vacatons. The result would be the page showing all photos
that satisfy the query (but the photos are not in sql server, but at a file location).
Any help would be greatly appreciated,
Sean
|
|
|
|
|
Have you even tried to search for anything? This is such an easy task, there are enormous amounts of info available for loading images from a path.
only two letters away from being an asset
|
|
|
|
|
in a javascript file containing is at below
var iWebAlbumPhotos = [{"caption": "e9fc5e5f477945b488cbb350794906cf", "url": "e6f6d95f3ceb49c99f7ced49b758c487.jpg", "comment": "ff"},{"caption": "2f8f1552240f4f70976f252d4c5e71cc", "url": "90f03060782f492f978f54f482be864b.jpg", "comment": "ffff"}];
how can i populate this at runtime in aspx page?
|
|
|
|
|
Lookup System.Web.Script.Serialization.JavaScriptConverter. I've only used it with WebServices, but there might be a way to hook into it for your aspx page.
|
|
|
|
|
hi
I am dynamically adding javascript controls and their events on the page.
That is working properly. But there is a cross browser issues –
Like my page working properly on the IE-6 and Mozill but not working in IE-7.0
So please tell me how to solve this issue.
Rajeev Kr. Sharma
VRI Software Pvt.Ltd.
New Delhi India
HumOnline.com
Stay Connected
|
|
|
|
|
there are issues which you will face. I would suggest to check the browser of user and then add javascript controls accordingly, as each browser has different architecture. Also i dont suggest adding javascript controls as they will not work if user has got javascript disabled on his browser,
Ahsan Ullah
Senior Software Engineer
|
|
|
|
|
Hi
I ahve a .asmx file which contains the code for my cascading dropdown
I have copied it from one project to another
Do I need to add any code anywhere else e..g webconfig to enable this file
any help would be great!!
thanks
|
|
|
|
|
if u have the code in a seperate file u will have to copy that file as well from app-code directory to the corresponding directory in the new project
Ahsan Ullah
Senior Software Engineer
|
|
|
|
|
if the control needs to be used in more than one project your better off writing it as a server control rather than a user control.
only two letters away from being an asset
|
|
|
|
|
asmx extension is for webservices not for user controls
Ahsan Ullah
Senior Software Engineer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
