|
Hi,
We're using asp.net 2.0, c#, and writing keys from HttpContext.Current.Request.ServerVariables to a log file. We're writing all keys except ALL_HTTP*, ALL_RAW*, VSDEBUGGER*, SERVER_*, HTTPS_*, CERT_*. Very often HttpContext.Current.Request.ServerVariables seem to have no values, and nothing gets written to the log.
Under which circumstances are HttpContext.Current.Request.ServerVariables null or empty?
Mostly, we need info about PATH_INFO, PATH_TRANSLATED, URL. Is there another way to get these so that we always have this info? HttpContext.Current.Request.ServerVariables does not always have this info.
Thanks.
Shefali
|
|
|
|
|
try response the value
you can see it is null or empty
I love li li huang ,
ha ha ,
but you don't who is she!
|
|
|
|
|
|
Are you not allowed to use Google in Bangalore? 5 seconds of searching turned this up.
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
|
I have a friend who manages an indian team in Bangalore. He says his team is very good, he works for Sun, so they hire and maintain an office. He says for companies where people find a company to handle one project, someone who can type, is a developer, and someone who can touch type, is a senior developer. My experiences with outsourcing make me think he's not exaggerating.
But, the bit where they don't seem to care if their manager sees them here, makes me wonder if some companies hire people and tell them to use CP to get the job done.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
hehehe their managers are the other guys from india posting in here! 
Abandon hope all ye who answer here.
Pete O'Hanlon - the General Discussions forum
|
|
|
|
|
One way or the other, I am certain there are people being employed who have no idea how to code, and who are hoping we will fill the gap.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Why you people always blame Indian guys?
I think you dont have a good experience with indian developers.
But trust me, you wd find the most intelligent, performing their jobs brilliantly developers in India too.
“The woods are lovely, dark and deep. But I have promises to keep, and miles to go before I sleep.”
|
|
|
|
|
LucknowRockers wrote: you wd find the most intelligent, performing their jobs brilliantly developers in India too.
I have no doubt. In fact, some of my best dev friends and people I respect highly, are Indian. And, like I said, when a company owns a team in India, my knowledge is only of cases where it works really well. But, every time I've tried to find an outsourcing firm to get some work done for me, it's been an utter disaster, and these forums are flooded with people from India, asking the most basic of questions and completely failing to comprehend the answers they get.
Not all bad devs are indian, nor are all Indian devs bad. But proportionately, it seems there are a lot of bad Indian devs loose on the web.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Christian Graus wrote: Not all bad devs are indian, nor are all Indian devs bad. But proportionately, it seems there are a lot of bad Indian devs loose on the web.
Can be true and the reason might be that the number of people here who are trying their hands in development is too huge that even the number of dumbs gets increased.
Apurva Kaushal
|
|
|
|
|
Yes Christian, I am totally agree with you and you are 100% correct.
As far as your experience with Indian developers is concerned, i would say that you are very unlucky. You always found only bad developers from India.
Why do not you give it another try and outsource some work to me  
“The woods are lovely, dark and deep. But I have promises to keep, and miles to go before I sleep.”
modified on Friday, March 14, 2008 11:48 AM
|
|
|
|
|
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. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
