I have started a session on my login.php page. I have used javascript.js file to send a request to the login.php page and get some data as response. I want to check on that js file if the session has been killed or has expired or is still started. If it is still started, then I would like to print or alert session array or name. Please help me.
The session is a server side thing, you cannot access it using jQuery. The only way to do this is to write the value into a script block on the page as a Javascript variable, and reference it that way, or to make an AJAX request to a page that then returns the logged in status. There's no way for your client to directly access the session state in any server language.
Related
I have a Jmeter script where during replay, Post request is displaying as Get request and the parameters in the request are not sent to the server. Due to this, correlations are failing at this request.
One of the parameters in the request is ViewState with so many characters. Is this large parameter value causing the above issue? How to proceed now?
Most probably you're sending a malformed request therefore instead of properly responding to a POST request you're being redirected somewhere (most probably to Login page)
Use View Results Tree listener in HTML or Browser mode to see what page you're hitting in the reality
With regards to the ViewState, "so many characters" is not a problem, the problem is that these are not random characters. ViewState is being used for client-side state management and if you fail to provide the proper value you won't be able to move further so you need to design your test as follows:
Open first page
Extract ViewState using a suitable Post-Processor
Open second page
here you need to pass viewstate from the step 1 along with other parameters
More information: ASP.NET Login Testing with JMeter
Also don't forget to add HTTP Cookie Manager to your Test Plan
What I'm able to understand is the request may be getting redirected. This happens usually when the server expects a unique request. If you recorded the request, you may be possibly using older headers that carry old cookie information. Check your headers and then reconstruct the request.
Make sure you are not using old cookies anywhere. remove that cookie part from HTTP Header Manager everywhere.
I have a legacy system which is running VB6 which I use to gather sensitive customer data. This data then needs to be passed to an internal web site. I don't want to pass the data as GET variables on the URL. I'd prefer to POST them. I've spend many hours googling this issue, but I'm yet to find a solution.
How do I open a browser at a specific URL with POSTed variables from a VB6 application?
To confirm for all the people who are going to read this, the web page must open in a browser. I don't want to parse the response from the web page in the VB6
If you're using the IE browser control, just place the parameters in the Postdata parameter of the Navigate method. When the Navigate method is called, if the Postdata argument is empty, a GET is performed. When the Postdata argument has data, a POST is performed.
i have to develop a java-applet which redirects to another webpage. Normaly i use the "showDocument(URL ul)"-method to do that. But in this case i have to send a lot of data to this page. So i need to do it via POST. But showDocument just allows GET-method.
My question: Is it possible to do a redirect to another webpage from within a japplet AND to send POST Data in the same request (like showDocument() but with POST data)? - I know that i can do a POST request from within the applet - but this will happen in the applet's context.
It's a bit complicated because the script from which the applet is called, runs on a client-auth protected server. So i need to do the requests with the browser (because he will be authenticated) - if i do these requests from within the applet, the applet have to authenticate again...
thanx
daniel
Directly with the Java Applet API this is not possible - showDocument is the only thing you have, and it supports only GET. You may be able to do something like this with the JavaScript bridge (i.e. call javascript functions from the applet, which then send the POST request to the server like the browser would (and show the result in a new browser window), but I never used this.
Trying to figure out a way where I can pass some data/fields from a web page back into my application. This needs to works on Windows/Linux/Mac so I can't use a DLL or ActiveX. Any ideas?
Here's the flow:
1. Application gathers some data and then sends it to a web page using POST that is either imbedded in the app or pops up a new IE window.
2. The web page does some services and then needs to relay the results back to the application.
The only way to do this that I can think of is writing the results locally from the page in a cookie or something like that and have the application monitor for a specific file in that folder.
Alternatively, make a web service that the application hits after passing control to the page and when the page is done the web service will return the data. This sounds like it might have some performance drawbacks.
Can anyone suggest any better solutions for this?
Thanks
My suggestion:
Break the processing logic out of the Web Page into a seperate assembly. You can then create a Web Service that handles all of the processing without needing to pass control over to a page.
Your application can then call the Web Service directly and then serialize the results and work with the data quite easily.
Update
Since the page is supplied by a third party, you obviously can't break anything out. The next best thing would be to handle the entire web request internal to your application (rather than popping a new Window).
With this method, you can get the raw HTTP response (and page markup) and work with it directly. You can then parse the Response stream and gather the required data from it.
During performing an HTTP request you should be able to retrieve the text returned by the page. For instance, if your HTTP POST was to hit a Java servlet, the doPost() method would be fired and you would then perform your actions, you could then use the PrintWriter object from the Response object (PrintWriter out = response.getWriter();) and write text back to the calling application. I'm not sure this helps?
The fact that
web page is hosted by a third party
and they need to be doing the
processing on their servers.
is important to this question.
I like your idea of having the app call a webservice after it passes the data to the third-paty web page. You can always call the webservice asynchronously if you're worried about blocking your application while waiting for results from this webservice.
Another option is that your application implements an XML-RPC server that can be called from the web page using PHP, Python or whatever you use to build the website
A REST server will do the job also...
I'm writing an actionscript library for an api. I use a URLLoader object to load data from the api. The problem I'm having is that whenever the api returns an http status in the 400s, actionscript treats this as an io error. This is all find and good, however, it seems like there is no way to access any data that was returned if this is the case. Consequently, any helpful xml about the cause of the error that gets returned is lost. Is there any way around this? It makes the library kind of a pain, if there can't be any useful information for developers when the api returns an error. Thanks for any help!
You can't get access to the data in an event of a 400. You can get the status code, however, by adding a listener for the HTTP status event.
If you control the back-end code, there are a couple of workarounds:
One option is to have the backend respond with 200s even in error cases when talking to a flash client, but with a special error code so the client knows that the 200 response is actually an error.
Another option is to set a cookie on the client containing the error message. Flash can't natively access cookies, but you can call out to javascript using ExternalInterface to read the cookie, or optionally the client can do another hit to a special back-end controller that reads the cookie and responds with an error message.