I needed to redirect the request to another action with TempData for specific requests.I know TempData uses session to store data.
If a request reaches to server01 and the request redirected with TempData to another action , will the request remain on server01 or may it goes to server02 ? If it goes to server02 , I will not be able to handle TempData properly.
Is there a way to keep the request on server01 for specific redirections ? or do i have to create a cookie which points the data on my db and check the request if cookie exist ?
Regards
Note: Loadbalancing is handled by a device out of the network where the servers located and the servers are not in a IIS Web Farm.
Is there a way to keep the request on server01 for specific redirections ?
You need to use StateServer or SQLServer to store your sessions instead of InProc. Another possibility is to configure your load balancer to always send requests from the same IP to the same server.
All those are very bad ideas of course. The best way to achieve that is to simply get rid of the session and TempData and design your application in a stateless, RESTFul manner. My favorite sessionState mode is the following:
<sessionState mode="Off" />
Related
I have an MVC 3 application that services requests on two different domains. Requests to firstdomain.com come from an iframe, requests to seconddomain.com come from a normal browser window. I need to use cookieless session in the iframe, but want to keep cookie-based session in the normal browser.
Normally the session type is determined in the web.config by setting the following:
<system.web>
...
<sessionState cookieless="UseUri"/>
...
</system.web>
But this applies to every request regardless of the domain. It would be possible to have two copies of the site on the server, one for each domain, and each having a different value for the sessionState cookieless setting, but I would like to avoid that for a number of reasons. Is there a way to toggle this feature depending on the domain of the request while running a single instance of the web application?
You could split the two into separate projects, each with their own web.config. That is one thought that would be better than two separate instances running.
Just out of curiousity, why cookies? Cache or Session would plausibly be better.
I have an ASP MVC3 website with a rest API service.
When a user passes in an invalid API or they have been blacklisted i wish to ignore the response.
I know I could send back a 404 or pass back an 503 but if someone keeps polling me then I would ideally like to ignore the response causing a time-out their end. Thus delaying the hammering my server gets.
Is this possible within ASP.net MVC3? If so any help would be most appreciated.
Thank you
For what you want, you still need to parse the request, so it will always consume server resources, specially if you have an annoying user sending a query every 500ms...
In this situations you would block the IP / Header of the request for a period of, for example 10 minutes, but it would be a very good idea to block it on your load balancer and prevent that request that even reach your application, this is easily accomplish if you're using Amazon Services to run your Service, but all other cloud provider do support this as well, if by any means you are using a cloud hosting.
if you can only use your web application, and this is a solution that is not tested, you could add an ignored route to your routing mechanism like:
routes.IgnoreRoute("{*allignore}", new {allignore=#".*\.ignore(/.*)?"});
and upon check that the IP is banned, simple redirect using for example Response.Redirect() to your site, to a .ignore path... or, why not redirecting that request to google.com just for the fun of it?
my question upfront is:
When changing from http to https: How do I enforce on Tomcat that the value of the JSESSIONID / (i.e. the session cookie) gets changed?
Here's my situation:
I assume we are having a potential security issue in our application and wonder how to fix it.
We run a JSF1.2 / Seam2 application inside of a Tomcat 6.x and force the usage of session cookies (no sessionid in URLs).
We allow http access, but when a user logs in we switch to https and stay on https.
We also do have a Filter that adds 'secure' to the cookie whenever the request is coming through https to ensure that the session cannot go back to http.
(somehow I thought Tomcat would do that automatically)
I noticed that the JSESSIONID doesn't change when switching between http and https.
This suggests to me that an attacker could potentially spy out the session cookie through http and then hijack the session.
So how can I tell Tomcat to use a different JSESSIONID when changing to https?
(Or if thats the default behavior: What could lead to this not happening anymore?)
Thanks for any hints/ideas!
some time (years actually) I posted this filter here that we use to renew the session ID after the login:
https://issues.jboss.org/browse/JBSEAM-2450
We call newSession() just after a login to mark the session-ID to be renewed on the next GET request (POST requests don't work well due to the restore of the view state, but the POST/REDIRECT/GET with Seam will issue GETs quite often).
You might want put it into your filter -- or you just mark your session to be refreshed in the next GET request. Just make sure that you don't renew your session when processing a JSF POST request.
Someone else also provided a Tomcat Valve to solve this
Best regards,
Alexander.
Is it at all possible to inject a request into IIS for a page, have IIS and ASP.Net handle it as normal, but get the response as html handed back to me programmatically?
Yes, I know that I could connect to port 80 using WebRequest and WebResponse, but that becomes difficult if you are accessing the IIS server from the same physical machine (loopback security controls et al).
Basically, I want to inject the request (eg for http://example.org/MyPage.aspx) between the points at which IIS would normally talk to the browser, and the point at which it would route it to the correct ASP.Net application, and get a response back from IIS between the points at which ASP.Net/IIS applies the httpfilters and hands the html back to the browser.
I'm predominantly working with IIS7 so if there is a solution that works just for IIS7 then thats not an issue.
You could implement a custom HttpModule, which would give you access to the IIS pipeline, including the final response. However, you would still need to initiate a request to IIS to actually kick off processing. Not sure if this would work for you.
From the MSDN documentation:
An HTTP module is an assembly that is
called on every request that is made
to your application. HTTP modules are
called as part of the request pipeline
and have access to life-cycle events
throughout the request. HTTP modules
therefore let you examine incoming
requests and take action based on the
request. They also let you examine the
outgoing response and modify it.
Gave you looked into the WebCkiebt class? You can make the request and get the response HTML.
http://msdn.microsoft.com/en-us/library/system.net.webclient.downloadstring(v=VS.100).aspx
I have developed an application with JSP and Flex. In that Flex application interact JSP with HTTP service. I deployed application in one server that server URL is with HTTP it is working fine. But when I deployed this project in another server (HTTPS) the application is not running. There in JSP session is not handled. Is there any server configuration whicn needs to be checked?
I have no idea what you're talking about with "session is not handled". Please elaborate the problem in developer perspective, not in enduser perspective. What exactly happens? What exactly happens not?
I can at least tell that sessions are usually backed by cookies. Cookies on its turn are usually bound to a specific domain and path. Cookies are not dependent from the protocol used. Roughly said, if the webcontainer has created a cookie to track the HttpSession, it will by default use the request.getServerName() as cookie domain and request.getContextPath() as cookie path.
So if you for example have this webapplication on http://example.com/context, then the cookie will be created for host example.com and path /context. Regardless of the protocol. But when you fire a request on http://example.com/anothercontext, then by default you won't get the same cookie back and thus also not the same session.
However, most webcontainers provides configuration options which can influence the cookie host and path. Tomcat, for example, supports an emptySessionPath attribute in the HTTP connector which causes that the cookie path is always /. This way the http://example.com/context and http://example.com/anothercontext will be able to share the same cookies and thus also the session.
This knowledge of how it all works "under the hood" must give a better understanding of your problem and thus also ease nailing down of the root cause.