I have a Java applet related problem and I would appreciate your help. Here's the story:
I tried creating an applet, that would try to connect to digg.com and by using it's API, show the 100 most popular stories (also include some options to sort and filter the results).
Anyway, the applet opens and shows the GUI just fine in the browser, but when I press the button that loads the news, it won't load them, BUT the news are loaded, when I run the applet in Eclipse.
I thought, that maybe the problem is related to creating the runnable jar from eclipse, since I have some referenced libraries (Google GSON for handling JSON from digg.com). Here are the settings I used for creating the runnable jar (I also tried "Package required libraries into generated JAR):
http://img816.imageshack.us/img816/417/exportjar.png
Here's a picture of the applet (ran from eclipse), when the news have been loaded:
http://img841.imageshack.us/img841/9121/applet.png
I would appreciate any ideas on how to get loading the news to work in the web browser.
I think torah is right. Applets should be able to connect only to their own server. You can try and trick the browser, sending request back to your server asking it to retrieve the data and to return it to applet.
What happens when you attempt to open the connection to digg? Is there a security exception? I wouldn't be surprised to learn that the JVM inside the browser was implementing a same origin policy. If this is the case there should be some kind of Exception (SecurityException I think) being raised when you try to connect to digg.com.
A quick search for "same origin policy java" found the following article which both seems to confirm that this could be your problem.
http://www.zdnet.com/blog/security/defeating-the-same-origin-policy-part-1/946
Related
I'm using latest version of Swagger in my ASPNetCore 3.1 project and debugging on latest version of Chrome. When I try to enter swagger page it sometimes not loading and i see an empty page. It looks like totally random. It solves after I refresh the page.
I saw these errors on console.
GET https://localhost:44389/swagger/swagger-ui-bundle.js net::ERR_HTTP2_PROTOCOL_ERROR
index.html:95 Uncaught ReferenceError: SwaggerUIBundle is not defined
at window.onload (index.html:95)
File in the error is random. Its sometimes a js file, sometimes a .css file. It changes.
If I publish this project on IIS and disable Http/2 support I never encounter this error.
Why?
You can try the following：
1.Check if all your controller methods have [http] tag. If they all do and still doesn't work go to step 2
2.In your configure function to ensure that you have app.UseStaticFiles(); If it still doesn't work go to step 3
3.Uninstall and reinstall swagger. If it doesn't work go to step 4 (Core Only)
4.If you are using Core Install Microsoft.AspNetCore.StaticFiles and reference it in your project.
I encountered the same problem, SwaggerUIBundle is not defined, and the problem is not on the web app that I'm developing but on my network. The problem was resolved after I switch to another network.
I'm getting this chrome flag when trying to post and then get a simple form.
The problem is that the Developer Console shows nothing about this and I cannot find the source of the problem by myself.
Is there any option for looking this at more detail?
View the piece of code triggering the error for fixing it...
The simple way for bypass this error in developing is send header to browser
Put the header before send data to browser.
In php you can send this header for bypass this error ,send header reference:
header('X-XSS-Protection:0');
In the ASP.net you can send this header and send header reference:
HttpContext.Response.AddHeader("X-XSS-Protection","0");
or
HttpContext.Current.Response.AddHeader("X-XSS-Protection","0");
In the nodejs send header, send header reference :
res.writeHead(200, {'X-XSS-Protection':0 });
// or express js
res.set('X-XSS-Protection', 0);
Chrome v58 might or might not fix your issue... It really depends to what you're actually POSTing. For example, if you're trying to POST some raw HTML/XML data whithin an input/select/textarea element, your request might still be blocked from the auditor.
In the past few days I hit this issue in two different scenarios: a WYSIWYG client-side editor and an interactive upload form featuring some kind of content preview. I managed to fix them both by base64-encoding the raw HTML before POSTing it, then decoding it on the receiving PHP page. This will most likely fix the issue and, most importantly, increase the developer's awareness level regarding the data coming from POST requests, hopefully pushing him into adopting effective data encoding/decoding strategies and strengthen their web application from XSS-type attacks.
To base64-encode your content on the client side you can either use the native btoa() function, which is supported by most browsers nowadays, or a third-party alternative such as a jQuery plugin (I ended up using this, which worked ok).
To base64-decode the POST data you can then use PHP's base64_decode(str) function, ASP.NET's Convert.FromBase64String(str) or anything else (depending on your server-side scenario).
For further info, check out this blog post that I wrote on the topic.
In this case, being a first-time contributor at the Creative forums, (some kind of vBulletin construct) and reduced to posting a PM to the moderators before forum access it is easy for one to encapsulate the nature of the issue from the more popular answers above.
The command was
http://forums.creative.com/private.php?do=insertpm&pmid=
And as described above the actual data was "raw HTML/XML data within an input/select/textarea element".
The general requirement for handling such a bug (or feature) at the user end is some kind of quick fixit tweak or twiddle. This post discusses the option of clearing cache, resetting Chrome settings, creating a new_user or retrying the operation with a new beta release.
It was also suggested that one launches a new instance with the following:
google-chrome-stable --disable-xss-auditor
The launch actually worked in this W10 1703 Chrome 061 edition after this modified version:
chrome --disable-xss-auditor
However, on logging back in to the site and attempting the post again, the same error was generated. Perhaps the syntax wants refining or something else is awry.
It then seemed reasonable to launched Edge and repost from there, which turned out to be no problem at all.
This may help in some circumstances. Modify Apache httpd.conf file and add
ResponseHeader set X-XSS-Protection 0
It may have been fixed in Version 58.0.3029.110 (64-bit).
I've noticed that if there is an apostrophe ' in the text Chrome will block it.
When I update href from javascript:void(0) to # in the page of POST request, it works.
For example:
login
Change to:
login
I solved the problem!
In my case when I make the submmit, I send the HTML to the action and in the model I had a property that accept the HTML with "AllowHTML".
The solution consist in remove this "AllowHTML" property and everything go OK!
Obviously I no longer send the HTML to the action because in my case I do not need it
It is a Chrome bug. The only remedy is to use FireFox until they fix this Chrome bug. XSS auditor trashing a page, that has worked fine for 20 years, seems to be a symptom, not a cause.
I'm using Windows 10 Technical preview. I know it's not yet tweeked out to full usage, but here is my problem.
On local IIS I'm developing my web app. It loads most of the data via ASP.NET MVC API. After the upgrade to Windows 10 I started to get
net::ERR_SPDY_PROTOCOL_ERROR
for all AJAX calls to API. The HTML page loads normally, but the dynamic loading of data content fails. I managed to figure it out by starting Chrome with parameters
--use-spdy=off --use-system-ssl
Strange thing is that on the first start I always get this error and have to restart Chrome. Other browsers fail too, but not with specific error. For the transfer there is used HTTP2.0 protocol, which is based on SPDY protocol.
Do I have to turn something off in IIS?
Edit:
Seems like an IIS problem with HTTP2.0. When trying to enter the site from Windows 8.1 I get the same error.
Most people’s reaction to this error would be to reload the web page. We would actually recommend this as a first response. Sometimes this even does work.
Interesting Factoid: SPDY actually stands for “speedy” and is used to reduce a web pages’ load time
If reloading the web pages does not remove the error, then you should close down Google Chrome and restart it. This alone will not really solve the problem because you will need to clear the cache as soon as you restart the browser.
or in cmd clear dns using this command ipconfig/flushdns
Im trying to make connections 4.5 working with content manager. I guess im quite far away from start finally but there are many things i need to fix.
Sometimes my widgets just doesnt load. It says cannot load widgets-config.xml
when i restart deployment and appsrv everything looks good.
My biggest problem is to add library to community. Because i want to see how workflow works and the id like to create linked library of this. This is what i get when i try to add library widget to the community (linked library widget works well)
CLFWZ0004E: Event 'widget.added' sent to remote lifecycle handler at https://conserv.egroup.local/dm/atom/communities/feed returned bad response: 403 - Forbidden
I guess there is som problem with https access. Can anybody of you guys ever faced this problem? Some hints?
UPDATE-1
After accessing that page from it gives me this :
<td:error>
<td:errorCode>UnsupportedOperation</td:errorCode>
<td:errorMessage>CQL5602: The attempted operation, GET, is not allowed on the resource /communities/feed.
Contact your administrator and provide the incident ID: 1381320497551.
The administrator should forward this information to the application owner.
</td:errorMessage>
</td:error>
So i guess maybe there can be som problem with proxy policies. I tried to make some changes with changes default policy url to *. But still no progress..
Hints?
I'm writing what is essentially a browser in Adobe AIR (ActionScript, not AJAX). A great bit of functionality to implement would be protocol handling. iTunes, for instance, handles itms protocols; when your friend sends you a link beginning with "itms://", it's going to launch iTunes as long as it's installed. Is there a way to write an AIR app (requiring AIR 2 would be fine) that can be the "handler" for a protocol in this way?
There is no way, programatically speaking, to specifically handle a particular protocol. However, there is InvokeEvent. InvokeEvent will be fired when the application is "invoked", either when it's explictly launched or if an associated file or URL is activated.
The process of associating your app with a particular file type or protocol scheme is separate and application-dependant. In iOS, for example, you would need to specify the protocol in Info.plist under CFBundleURLTypes/CFBundleURLSchemes.
Yes. You can use the URLLoader class to download data in binary form (URLLoader.BINARY) and then parse this as appropriate. See this CS3 documentation on working with external data.
http://www.patrick-heinzelmann.de/labs/lastfm/
I'm not sure exactly how it works and I don't see a way to download the app, so I can't even test it, but maybe it will help...
Check out this page. I am trying to find out the same thing, but I haven't found any solution to do it with just Air yet. Seems like you might need a custom installer to setup the correct registry entries, and a proxy application to "wash" the input to a correct format that then can start your application with the correct command line parameters. Hope this can be of any assistance.