I am using the CefSharp .Net wrapper for the Chromium Embedded Framework as a simple wrapper around a web application. In my web application, I make a JSONP AJAX call out to another domain to get some data and display it. The URL to that domain is not using SSL. Because of that, when doing this in the Chrome browser, I get the following message, to which the end user would simply click "Load Anyway", allowing the JSONP request to fire and the data to be retrieved...
The app using CefSharp simply starts up the main URL to my web application when it runs. When I try and make the same call in my this application using CefSharp, however, it doesn't get that same prompt. Instead, the AJAX request just times out (the same behavior that happens when the end user never clicks a button in the yellow bar that appears in Chrome).
Does anyone know if CefSharp has a way for me to catch this security message and either...
Prompt the end user to click "Load anyway", similar to the behavior of the Chrome browser, or
Programmatically bypass the security warning altogether?
If not, does the Chromium Framework itself support dealing with this situation?
After posting to CefSharp and CEF projects, it looks like CEF does not currently support this situation. magreenblatt suggested a couple of approaches to add it to CEF. Now I just need to try and find the time to add support for it. :-)
Related
The question is probably easily misunderstood, so I'll go into more detail:
I am trying to automate a task in a certain (very outdated) browser-based idle game that is written in PHP in order to polish my portfolio with a little more variated projects.
I used DevTools to reverse most of the requests and wrote a small C# Request wrapper to test them. I can get most of the actions I want to work, using the respective ajax get requests and the correct cookies/headers - not really part of the problem.
Example:
Attacking an enemy:
https://somebrowsergame.com/game/ajax.php?mod=location&submod=attack&location=3&stage=2&premium=0&sh=****mysessionhash****
Making a GET request to this URI with the correct headers and cookies, I can perform the in-game action programmatically and successfully from my C# console application and see that the fight has taken place when visiting the site in the browser.
The problem:
When monitoring all requests after clicking the "attack" button, via DevTools, even with preserve logs enabled, I don't see any redirects or way of determining how my browser gets told where to navigate to.
Findings
I found out that the button calls a javascript function attack() in its onClick event and tried debugging the javascript in DevTools in order to find out where somethign happens (such as setting document.href or smth), but when Debugging I ran into a seemingly infinite loop of setInterval handler and setTimeout handler in the call stack.
I also cleared the Network tab after the onClick event (and after the ajax request which I could find during Debugging) but the only request/response I got was the document GET request for the final page, no request telling my browser which site to navigate to.
Monitoring requests
The request made to initiate the action (via button click on website or ajax GET request as outlined above)
The document response / site navigated to
What I want to know is how my browser got told which site to navigate too, as the request URI for the document request (getting the html of the target page) has a parameter generated on the server side (logId)
I have also used "All" request types in DevTools, as well as negative filters when monitoring requests but never was I able to see how my browser knows which page to navigate to. I tried with source breakpoints at "beforeunload", tried inspecting the javascript source connected to the onclick event of the button (which didnt give me anything, as the js is minified and barely readable - i am not even sure if the navigation is done via window.target.href) and googled this question in all possible wordings which lead me nowhere
I am not too versed in web development, but I am sure my browser has to be told where to navigate to in some fashion after clicking that button?
I've added Roxy Fileman to my project and tied it in to CKEditor. It's a standard Durandal project with an MVC controller for routing and a web api controller for ajax/json data calls.
A typical working URL for a web api call in my app is http://localhost:63093/api/DurandalApi/getAssessmentQuestionnairePushMenu?id=1
When I try and upload a file from within CKEditor, I get:
Request URL:http://localhost:63093/fileman/index.html?type=image&CKEditor=ckeditor&CKEditorFuncNum=1&langCode=en
Request Method:POST
Status Code:405 Method Not Allowed
Remote Address:[::1]:63093
If, however, I directly go to http://localhost:63093/fileman/index.html?type=image&CKEditor=ckeditor&CKEditorFuncNum=1&langCode=en in my browser, the file upload works perfectly and I can then browse to the image from FileMan inside CKEditor.
The network tab in chrome dev tools indicates that the successful upload is done using this URL: http://localhost:63093/fileman/asp_net/main.ashx?a=UPLOAD which is significantly different to the one that CKEditor attampts to use, but that may be because in the second example, index.html is already loaded?
I'm not completely up to speed with what's going on, but the fact that the same URL works perfectly outside of Durandal if I go directly to the URL seems to indicate the FileMan plugin is working just fine and all permissions are set accordingly. Furthermore the CKEditor config is also fine as it can see the images I upload in the directory, but for some reason it's unable to "post" from within CKEditor (which is embedded in a standard Durandal view).
I'm trying to read up on routing to see if I need to do some kind of exception mapping in Durandal to tell it to let the 3rd party .ashx handler deal with the POST request and I'm not even sure if this problem is indicative of Durandal getting in the way or something else. Any suggestions gratefully received!
Ah. All has become clear. This is a half and half answer really as it doesn't really solve the problem, but equally the problem doesn't really exist!
The issue is that Roxy Fileman does NOT use the CK Editor inbuilt "upload" tab that is in the popup. It expects the user to "browse server" only and use the "add file" link in Roxy instead.
I was confused by the instructions, but now I understand!
I've got a communication between client and server. The process is simple:
I'm making an AJAX POST request to a controller which generates a pdf in the file system
On success of the above request a form GET request is made to get the pdf back and the standard browser "save or open" dialog box opens up
The reason I'm having a two step process is because I need to have a progress bar while the pdf is being generated.
The reason of the second request being a form submit rather than part of the AJAX request is because I can't get the standard browser "save or open" dialog box.
The problem with this approach is that IE7 & IE8 pop up a their annoying notification bar notifying the user that the it is dangerous to download the content and I don't want that.
So:
I need the progress bar.
If I go for an AJAX request only I need a way to pop up the "save or open" dialog box.
If I go for the a form GET submit I need a way of knowing when the file has been generated in order to stop the progress bar, something like a shared flag between server and client.
Any help appreciated.
One possible (a little of an anti pattern) workaround is this, but it's not a great design probably
However I've seen this (and admit I did this) before, and except some guilt, it did the trick
user clicks a link that goes to the servlet that generates the PDF and will just wait (timeout settings should be applied) until it's ready... (Content-Disposition header etc...) just like a regular download
The servlet will report progress on a shared session variable while generating the PDF
an AJAX call to the server will read from the session variable the progress and show to the user
when the PDF is done, the browser will just download it (request timeout risk perhaps)
The main issue here is using the request thread as a worker thread and blocking it, which may give this answer a couple of downvotes...
I'm not that familiar with Message Driven Beans but this is another, probably better solution.
I have a webpage with a hyperlink "myapp://mypage?id=123456&name=hello" , clicking the link is supposed to trigger the webbrowser Navigating event so that I can catch the url and do something meaningful. The problem here is that the Navigating event is not triggered at all.
I tried normal website eg: "http://xxxx.com" and it works. So is there a way to deal with user custom urls with webbrowser control?
ps: IsScriptEnabled is True
thanks
From my investigation into this, WebBrowser.Navigating only gets called if you attempt a hyperlink when using the file, http and mailto protocols. Custom protocols are not even served.
Digging around the web for custom extensions leads me to believe that it is possible to implement something that works around it, but doing so would be a great deal of headache and pain.
If you do/did find anything, please post it, as I would be interested to see your solution.
I'm trying to figure out right configuration for cross origin AJAX call in Safari extension injected script.
My configuration in Extension Builder:
Extension Website Access: All
Include Secure Pages: true
Whitelist: -
Blacklist: -
My goal is to get something like Chromes "permissions": "http://mysite.com/*", and be able to pull user configuration from web service.
note: JSONP drops warning, so I would prefer to avoid it.
Any luck with this? I'm having the same problems. Same setup works fine in the Chrome extension, but hitting Access-Contol-Allow-Origin when trying to do it in Safari Extension.
FIXED - UPDATE:
Hey, I figured out what the problem is. So, it looks like you need to do the cross-domain ajax via the background page. What I end up doing is determining all the requests I need to make in the injected script, then message pass the requests to the background page. The background page listens for messages from the injected script, makes the appropriate ajax calls, and then sends the results via a message to the injected script. The injected script is then listening for messages from the background page, once it gets the message(s) with the ajax results, it takes the appropriate action in the page that's being viewed.