it is all a matter of “user friendly”, your middle finger could also work as well to open image,source code,video in a separated window, no ?
really thinking about possible hack caused by IFRAME is strange when we links to so much signed Applet & JWS that enable “keys logging”, fishing,… those are IMO a lot more dangerous in terms of security
As far as I can tell, the only thing preventing the use of an iFrame is a ‘theoretical future browser bug’. That’s a silly reason to disallow this.
So you would visit any website on the internet?
With an iframe, you can embed any webpage on the internet… never heard of a ‘drive by attack’ ?
I’m not suggesting letting people embed their own content within the iframe. I’m suggesting people add the parameters they need for their applet, and then JGO generates the iframe.
To me that seems the most natural solution.
What’s the point of creating an iframe for an applet… it makes no sense to embed a subdomain, because it doesn’t help much for security.
I believe with applets you can interact with the website they are hosted within (at least you can with NetScape browsers). So a user could potentially upload an applet that grabbed the users cookie. Placing the applet within an iFrame prevents this.
Ultimately 99% of users will just want to be able to: upload their applet and write an applet tag (which could be done via BB code to ensure it’s safe).
This issue IMO is one about scope and what we expect from JGO, do we want it to go as far as a full blown java games portal or remain as a simple java games related forum (or somewhere in between).
If just a forum then I see no reason why there is a need to have embeddable applets. External links work just fine, plus we have sites like Games4j.com and GameJolt.com which are both excellent hosts for such stuff. Also as of Java 1.6.0_10+ applets can access and change everything about the webpage they are on (MAYSCRIPT no longer does anything) and it’ll just be an extra annoyance since you can do stuff like add background music to pages, open pop ups, etc.
If however the intention is to move closer towards a games portal then I’m all for having applet support and stuff like community voting on games, etc.
I don’t think the forum should host applets. Who cares if the link breaks.
I think the applets bb code (or w/e) should be restricted to the first post and only on the showcase areas.
If someone is changing the forum looks with applets then delete the post and ban the user if needed.
Add JavaScript loading of the applet for people who don’t like applets starting straight away.
You could also make it so users with X+ amount of posts or appreciation can post applets.
It’s much more streamlined if people can host (or at least embed) their applets here.
[quote=“kappa,post:27,topic:36082”]
Again wrapping the applet within an iframe will prevent this.
From the impression of the posts above security seems to be the main reason this won’t ever be built, but I still fail to understand what these security concerns are.
I think this is a great idea, it should filter alot of potential problems, even as far as people not testing applets on the main OS’s. because you always get Mac developed applets crashing on windows, and visa versa. It would be nice, if its just the more experienced users contributing to a streamline JGO.
http://usablelayout.com/articles/automatically-break-out-iframe
and you can access and modify things in the parent of an iframe from a child iframe.
no you should not be able to acces DOM of the parent iframe if it come from another domain, this one is IMO twice wrong, first it use page from the same domain, second it does not really acces DOM of the parent iframe but just change the location of the main window
According to this applets cannot communicate with JavaScript by default. It needs to be turned on via the ‘mayscript’ applet attribute. So I stand corrected, an iframe isn’t even needed.
Again, as long as JGO is generating the applet tag are there any security concerns?
to be safe you have to embed the iframe from the author domain, everything must come from the external domain and nothing from JGO, this will ensure that everything will be keep separated by the browser
as mentionned above, a minimum number of post is a nice idea too
As mentioned above, since Java 1.6.0_10+ (which is now over 60% of java installs) the mayscript attribute no longer does anything. JavaScript communication is allowed by default, haven’t seen a switch to allow disabling it yet.
Anyone knows people of Funorb? They have a nice solution for applets, I know it is a different platform (not a forum) but they could be of help
All their applets are written in-house, so are all from trusted sources.
(LWJGL) Applets are (hopefully) functional now:
[lwjgl archive=jgolwjgl.jar class=jgolwjgl.JgoLwjglApplet width=512 height=512]
It should look like a 512x512 black rectangle with a single triangle rendered. Please test! :-*
Syntax:
// lwjgl applet
[ lwjgl archive=your.jar class=your.Applet width=512 height=512 ]
// just like your regular applet
[ applet archive=your.jar class=your.Applet width=512 height=512 ]
I will have to add the upload feature later.
I don’t quite get why there isn’t some abstract class in LWJGL that you extend for your applet, I had to rip out code from the GearsApplet demo, resulting in rather messy and verbose code to render 1 triangle, which IMHO the developer shouldn’t be exposed to. Anyway, I disgress… Here’s the code to get that triangle on screen:
import java.applet.Applet;
import java.awt.BorderLayout;
import java.awt.Canvas;
import org.lwjgl.LWJGLException;
import org.lwjgl.opengl.Display;
import static org.lwjgl.opengl.GL11.*;
public class JgoLwjglApplet extends SuggestedTemplateApplet
{
public void drawTriangle()
{
glBegin(GL_TRIANGLES);
glColor3f(1, 0, 0);
glVertex3f(-0.5f, -0.5f, 0.0f);
glColor3f(0, 1, 0);
glVertex3f(+0.5f, -0.5f, 0.0f);
glColor3f(0, 0, 1);
glVertex3f(+0.5f, +0.5f, 0.0f);
glEnd();
}
@Override
@@ public void displayReady()
{
glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
while (running)
{
glClear(GL_COLOR_BUFFER_BIT);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
drawTriangle();
Display.update();
try
{
Thread.sleep(100);
}
catch (Exception exc)
{
//
}
}
Display.destroy();
}
}
public abstract class SuggestedTemplateApplet extends Applet
{
Canvas holder;
Thread gameThread;
volatile boolean running;
void startLWJGL()
{
gameThread = new Thread()
{
public void run()
{
running = true;
try
{
Display.setParent(holder);
Display.create();
}
catch (LWJGLException e)
{
displayFailed(e);
return;
}
displayReady();
}
};
gameThread.start();
}
@@ public abstract void displayReady();
@@ public abstract void displayFailed(LWJGLException exc);
void stopLWJGL()
{
running = false;
try
{
gameThread.join();
}
catch (InterruptedException e)
{
e.printStackTrace();
}
}
public void destroy()
{
remove(holder);
super.destroy();
}
public void init()
{
setLayout(new BorderLayout());
try
{
holder = new Canvas()
{
public void addNotify()
{
super.addNotify();
startLWJGL();
}
public void removeNotify()
{
stopLWJGL();
super.removeNotify();
}
};
holder.setSize(getWidth(), getHeight());
add(holder);
holder.setFocusable(true);
holder.requestFocus();
holder.setIgnoreRepaint(true);
setVisible(true);
}
catch (Exception e)
{
System.err.println(e);
throw new RuntimeException("Unable to create display");
}
}
}
It works on Mac 10.6 in Safari 5, which is impressive since I usually see applets fail.
Is there a reason why there are two tags, one for LWJGL and one for regular applets? I haven’t made a LWJGL applet before, so I don’t know if you need to configure it differently.
oh nice work, really awesome how you are gradually improving JGO.
testing:
[lwjgl archive=http://kappa.dreamhosters.com/test/boing/ball.jar class=org.bossattack.boing.BallApplet width=640 height=480]