Recently, i have embedded a third party applet for the web project.
The applet provides some predefined parameters and i can use it into JSP file. For example:
<APPLET CODEBASE="XXXXX" .......>
<PARAM NAME="downloadLink" value="http://xxxxxxxxx?imageId=xxxx">
</APPLET>
However, i think it is not security due to the parameters and its value can be viewed through "view source" function which provided by the browser. Therefore, users can get the download link easily and re-download the image by typing the link in address bar.
In the above situation,
1. How can i avoid the parameter and its value displayed in jsp source?
2. is it possible to load the parameter list from java script/html/json etc...?
It depends on what level of security you want.
What probably would work for most users and solve your 'looking at the html source' problem is:
You could encrypt your parameters on the server and then pass them to your applet (with the 'param' parameter as you did) and then decrypt those params in your applet again. Then you won't see anything meaningful when you look at the html source. However a user could theoretically decompile the applet and extract the key and thus decrypt your params... So as mentioned it depends on the level of security you need.
Related
I want to stress test a system based on Apache Wicket, using grinder.
So what I did was that I used grinder's TCP Proxy tool to record a test session in my Application and then fed the generated test script to grinder to stress test the system; but we found out the tests aren't carried out successfully.
After a lot of tweaking and debugging, we found out that the problem was within the wicket's URL generation system, where it mixes the page version number into its URLs.
So I searched and found solutions for removing that page version number from the URLs (Like this), and used them and they worked and removed those version numbers from the URLs used in the browser. But then again, the tests didn't work.
So I inspected more and found out that even though the URLs are clean now, the action attribute of forms still use URLs mixed with page version number like this one : ./?4-1.[wicket-path of the form]
So is there anyway to remove these version numbers from form URLs as well? If not, is there any other way to overcome this problem and be able to stress test a wicket web application?
Thanks in advance
I have not used grinder, but I have successfully load-tested my wicket application using JMeter Proxy; without changing Wicket's default version mechanism.
Here is the JMeter step-by-step link for your reference:
https://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.pdf
Basically, all I did was running proxy server to accept web requests from the browser to capture the test scenarios. Once done collecting the samples, then change the target host url to whichever server you want to point to (other than your localhost).
Alternatively, there is another load testing tool BlazeMeter (compatible with JMeter). You could add the chrome browser plugin for quick understanding.
Also, you might want to consider mounting your packages to individual urls for 'cleaner' urls. That way, you have set of known urls generated for pages within same package (for example, /reports for all the reports pages within reports package).
Hope this helps!
-Mihir.
You should not ignore/remove the pageId from the urls. If you remove them then you will request a completely new instance of the page, i.e. you will lose any state from the original page.
Instead of using the href when recording you need to use the attribute set (by you!) with org.apache.wicket.settings.DebugSettings#setComponentPathAttributeName(String).
So Grinder/JMeter/Gatling/... should keep track of this special attribute instead of 'href' and later find the link to click by using CSS/XSLT selector.
P.S. If you are not afraid of writing some Scala code then you can take a look at https://github.com/vanillasource/wicket-gatling.
Are there any validators for Eclipse that checks that internal links between JSF web pages in the same project refers to existing pages?
I realise this is impossible to do in more complex cases, but it should be possible to do in the standard case.
One way to achieve something similar is to create Java constants for all page source files names (for example as properties in an app scoped bean) and reference them from EL, because EL validation checks those. But to do this you have to manually add all the file names which is cumbersome.
I have a simple Java applet with several text fields for input.
I would like to be able to somehow cache what the user enters into these fields so that next time they run the applet, they can make a selection from a list of previous inputs.
I have been searching forums and sites and cannot find any way to do this for applets.
Does anyone have a suggestion or a kick in the right direction?
If you're running this in a browser, you could try using cookies.
As well as cookies, here are a few more possibilities.
HTML5 offers Web Storage which can be accessed from the applet using JS.
An applet running in a Plug-In 2 JRE can be deployed using JWS and use the PersistenceService to store data. Here is a demo. of the PersistenceService.
A trusted applet can read/write the local file-system, but probably overkill for this.
I want to use BIRT in an RCP application. I'll need to allow the user to enter parameter values and it's a requirement that the parameter entry UI must be customizable by users without compilation.
Is the only way to build a custom parameter JSP page and show it in an embedded browser? Or are there other ways to do this?
Besides the custom jsp, you can build your own SWT-UI that asks in your RCP for parameter values. You have to
parse the rptdesign file by BIRTS API to examine the parameter-types
prompt for example your custom dialog and
afterwards opening an embedded browser with the entered parameters (the parameters are appended to the URL of the ReportViewer), see also http://www.eclipse.org/birt/phoenix/deploy/viewerUsage.php#parameters
Well, well, here we go...
We have a java applet running on a regular browser (ff4+ or ie5+).
I do NOT have access to the java code / servlet. Nor even to the server.
I NEED to send/retrieve data from this applet. This means i must emulate an user onto it by clicking buttons and filling form's textboxes and also return data (after server response) wich ll be inside textboxes.
So the technologies avaibles to be used are C, VB, .NET (webbrowser object mainly), PHP (cUrl avaible), JavaScript, Sniffing the browser/server communication using Fiddler.
We really need this. But if thats impossible so we may have to know also.
The data is owned by my company so no copyrigth is inflicted.
Also i'm open to non traditional solution such as saving the html as an image and then retrieve the data using some OCR software...
Well so any suggestion or pointing directions would be gratefully appreciated.
Thx
Paulo Bueno.
Having to emulate a user browsing is wrought with problems and i would suggest an alternate route, if its feasible. These are the steps I would take:
Grab the applet class or jar from my cache (anyone accessing the page / applet can do this).
Decompile the code into Java source (Using jad or other preferred tool)
Review the process with which the applet communicates to the service
Write an application to submit my data to the service that the applet connects to and handle any responses just as the applet would.
You can run any applet without a browser using the "appletviewer" that is shipped in a JRE. This way it is possible but not practicable to read and send fake input with http://code.google.com/p/windowlicker/ to control the SWING GUI.
But within a regular browser environment with access to the code you would rather do this:
using the "scriptable" and "mayscript" attributes/elements in your object tag. standard browser JREs include a "plugin.jar" that contains the needed function to do this job. This interface lets Java-Applet code communicate vice versa to Javascript, from wich you can do whatever you want (i.e. ajax request)
this topic is rather complex, so check out what google tells us:
http://www.htmlcodetutorial.com/applets/_APPLET_MAYSCRIPT.html
http://www.raditha.com/java/javascript.php
Using this interface is a real pain, so i suggest to implement HTTPRequests within your applet to tell the PHP server whatever you want to tell it.
regards,
Michael
I do NOT have access to the java code / servlet. Nor even to the
server.
Emm... It is quite unusual situation. If you have the applet, of course, you should have access to its src files to modify :)
I NEED to send/retrieve data from this applet. This means i must
emulate an user onto it by clicking buttons and filling form's
textboxes and also return data (after server response) wich ll be
inside textboxes.
Anyway, to "emulate" user you can use the Robot object but still it will demand you to modify the applet code to make it support some additional functionality... As I can remember, JS etc cannot control Java Applet from the outside commands unless the applet does contain JS supported functionality for web page interaction... But still you say you don't have any access to the applet src so there is no information does the applet support netscape.javascript or not and how it support it so it is quite unclear... So I must ask do you have any docs of this applet?
Comming around the question text and getting back to the question title itself which says
"How can I extract data from a Java applet (inside the browser)"
I may suppose to say that
To extract data from Java Applet you can use netscape lib which supports Java Applet and JS interaction example, docs. That is the most optimal way in this case
Good luck
Might not be too difficult to de-compile/change/compile again the applet unless it is obfuscated.
I use JAD.
https://stackoverflow.com/questions/31353/is-jad-the-best-java-decompiler
If you must get your data by interacting with the java applet instead of reverse engineering it, check out FEST (Fixtures for Easy Software Testing). FEST is designed for testing Java Swing GUIs by simulating user interaction, but you can easily use it to automate your applet as well.
Check out the documentation page on testing applets to get started.