I originally asked a question about NSISDl because I thought there was a bug or issue with my use of it. Through this ticket, I found out it does not support HTTPS at all, and thus it became an entirely different matter. (edit)
NSISdl only supports plain HTTP. Use the INetC plug-in instead, it uses WinInet and should work anywhere Internet Explorer works...
Related
i'm using lead tools web scanner and trying to enable it to work on HTTPS.
Blockquote
can i get some help here
It appears you tried to quote something in your question but it did not show correctly.
In any case, if you’re using the current version 20 of LEADTOOLS, see this forum post with detailed information on How to Enable HTTPS in the LEADTOOLS Web Scanning Host.
If you’re using the previous version 19, there’s an older article that discusses that version here.
If neither of these pages helped you, send full details about what you tried and what problems you ran into to the support address support#leadtools.com. Our email support is free regardless of which version of LEADTOOLS you’re using.
When I go to https://dojotoolkit.org/, I get, "Unable to connect". In some browsers I get "You have reached a domain that is pending ICANN verification".
I've used a number of dojo libraries in my code. Does anyone know what happened to the owner and whether this is likely to be fixed in the near future?
If it isn't fixed, what is my best option for replacing it?
This seems to be a temporary administrative DNS issue, based on their Twitter response:
We apologize for the issues accessing the Dojo 1 web site. We’re
working on it as fast as possible. In the mean time, you can add the
IP address directly to /etc/hosts. 104.16.205.241
There are also some workarounds on the dojo gitter.im channel:
Reference guide content is also at https://github.com/dojo/docs/ And
tutorials are at
https://github.com/dojo/dojo-website/tree/master/src/documentation/tutorials
Also, as mentioned in this related question, you can use the Archive.org Wayback Machine.
The site now appears to be back up. I was able to access it and get information on features I'm using.
My WebRTC app works fine when I connect two of the same browsers, but when I try a combination neither respond to each others signaling messages. Something probably worth mentioning is that I have not implemented TURN, however I don't see why that should make a difference so I'm not going to change that unless I'm fairly certain it will.
I don't have much of a clue where the error lies, so I will just add code on request for the sake of readability.
Make sure you enable DTLS-SRTP (Firefox only supports DTLS-SRTP) by passing the following to the PeerConnection constructor:
{ 'optional': [{'DtlsSrtpKeyAgreement': 'true'}]}
See this page for more details.
You have not really described what goes wrong with the signaling. No error messages and so on.
But based on the fact that you only see the fault when using two different web browsers I would recommend using Adapter.js that have been somewhat promoted from webRTC.
Link to webRTC demo that shows on the interoperability using Adapter.js(page also contains a link to Adapter.js):http://www.webrtc.org/demo
Direct link to
adapter.js
Try to turn off your firewalls to check if it fixes the problem.
In my case (Windown 7), default windows firewall didn't allow UDP for Private Inbound Connection Setting and Firefox + Chrome p2p connection just didn't work.
Hope it helps.
I recently have an issue with colorbox. After moving the site in different server (cloud) the functionality of opening a link with colorbox, stopped working. The files are the same and I have not changed anything.
Do you have any suggestions? Is there any server compatibility that I have to look around?
Thanks in advance,
Penny.
Colorbox, and all jQuery and Javascript scripts for that matter, are client-based. This means it is the client (the visitor's computer) who does all the work. The server has absolutely nothing to do with them. This being said, the answer of to your questions is: no. There are no know (or even unknown) compatibility issues with colorbox and any time of server.
So, more than likely something went wrong with your files when you migrated to your new server.
I know you use the C based networking API to do FTP communication but I'd prefer to use something a little higher level. I've seen a few Objective-C based wrappers but I'm not sure what to use. I don't need that complex of FTP interaction. Its just the typical create/delete dirs, upload/download files... What do you recommend?
Edit:
Here is one that looks promising but I can't get it to compile for the iPhone SDK
The ConnectionKit
This may help, but you may reconsider design for reasons stated by bbum:
http://code.google.com/p/s7ftprequest/
The reason why you can't find much in the way of useful FTP client software is because FTP isn't used much any more and is generally actively discouraged from use.
Without great care, it is quite easy to create big old security holes when using FTP (when I ran a consulting company, the 3 times we had infected machines were all because of FTP server security holes or exploits -- one time, the damned HP copier's FTP server was the attack vector!).
FTP is also inefficient unless carefully configured.
I would encourage you to use an HTTP based protocol. WebDAV allows you to do basically anything FTP can do, but does so over an HTTP channel. Thus, it'll work through proxies and the like. Heck -- HTTP has become so ubiquitous that pretty much everything works with HTTP.
And, of course, there are plenty of good HTTP client APIs built for Objective-C.
Obviously, if FTP is a requirement for your project, this answer won't help you much....
After not finding anything that works well I decided I'd go ahead and follow Apple's tutorial on how to do FTP. It sure is a PITA but at least it does work. I'm defiantly going to support WebDAV in the first revision my app, and eventually perhaps some other transfer methods later on. I think I'm going to consider releasing this open source after I get FTP & WebDAV working good, since there is no reason why you should have to do this much low level work to do such a basic and ambiguous task as FTP these days.
I've implemented FTP file download and upload, directory create and directory list download through the regular FTP possibilities in the iPhone SDK. Note: you'd be passing the login name and password as part of every FTP request unsecured. Apparently no apparent connection to the FTP server is maintained at the app level, like with a real FTP client app, that I haven't been able to find for iPhone yet. If you're interested in the source code please let me know through e-mail.
GoldRaccoon isn't mentioned and can be found on GitHub. I use that library and it works very well (besides it didn't support FTP rename)