I'm attempting to make a mail client that is HTML5/JS only where users would have to define their mail server and credentials.
I've surfed google leading to dead ends and figured that this is the next best place (or superuser.com).
I was thinking of using HTML5 WebSocket if I could to make the connection to the server but I don't know enough of smtp, imap, or pop3's architecture to understand how javascript could pass the args and perform what I want it to do.
PHP cannot be involved in this project otherwise I wouldn't be asking the question.
Any help in locating this would be fantastic.
Nothing is impossible. Except this.
In standard HTML or JavaScript, you can't make raw-socket connections, which is what you'd need to speak any of the protocols you've listed. The WebSocket API doesn't help you, because the server must also speak WebSockets, and mail servers don't. This is actually all a good thing, though. Imagine if you visited a random website and it telnetted to your home router, setting it on fire and burning down your house. That's what websites would be able to do if they could initiate plain TCP socket connections.
You have a few options I can think of, neither of which involves building a webpage. (And to be clear, you didn't say your project had to be a webpage; you merely said HTML/JS, so these are indeed legitimate options.)
First is something like node-webkit. As the readme says, "You can write native apps in HTML and Javascript with node-webkit." You'll still have to distribute it as a native app, because that's what it is.
Second is a Chrome app, specifically using the chrome.socket API. But have fun writing a TLS layer over those sockets, which you'll find is a requirement for almost any mail server these days. If you succeed in doing that, you'll be able to distribute your mail client in the Chrome Web Store, where I assure you an email client will be quite popular.
Third, write a webserver that operates locally, so your users will visit something like http://localhost:9999/mail in their browser. This will be a real pain to distribute, but you can use almost any technology you want.
I'm sure there's a fourth valid option, and someone else can chime in on that one.
Best of luck.
Related
I'm new to HTML and coding period. I've created a basic HTML page. In that page i want to create dropdown selections that produce outputs from my SQL database. MSSQL not MySQL.
EX: If I select a table or a column from dropdown one and then input a keyword for selection box 2. I want it to produce a table that shows the information in that table/column with that keyword.
If I select a medical name from dropdown and I want it to show only medical names that are equal to Diabetes. and then show me those rows from my database to a table. How would I show that in HTMl from connecting to the database, to creating the dropdown selection linked to the database, and then being able to select the criteria for what I want to be displayed. and then showing that in a table or list format.
Thank you in advance
OK, Facu Carbonel's answer is a bit... chaotic, so since this question (suprisingly) isn't closed yet, I'll write one myself and try to do better.
First of all - this is a VERY BROAD topic which I cannot answer directly. I could give a pile of code, but walking through it all would take pages of text and in the end you'd just have a solution for this one particular problem and could start from scratch with the next one.
So instead I'll take the same path that Factu Carbonel took and try to show some directions. I'll put keywords in bold that you can look up and research. They're all pieces of the puzzle. You don't need to understand each of them completely and thoroughly from the beginning, but be aware what they are and what they do, so that you can google finer details when you need them.
First of all, you need to understand the roles of the "server side" and "client side".
The client side is the browser (Chrome, Firefox, Internet Explorer, what have you). When you type an address in the address bar (or click a link or whatever), what the browser does is it parses the whole thing and extracts the domain name. For example, the link to this question is https://stackoverflow.com/questions/59903087/sql-drop-down-selections-in-html?noredirect=1#comment105933697_59903087 and the domain part of that is stackoverflow.com. The rest of this long jibberish (it's called an "URL" by the way) is also relevant, but later.
With the domain in hand the browser then uses the DNS system to convert that pretty name into an IP address. Then it connects via network to the computer (aka "server") designated by that IP address and issues a HTTP request (HTTP, not HTML - don't mix these up, they're not the same thing).
HTTP, by the way, is the protocol that is used on the web to communicate between the server and the browser. It's like a language that they both understand, so that the browser can tell the server hey, give me the page /questions/59903087/sql-drop-down-selections-in-html. And the server then returns the HTML for that page.
This, by the way, is another important point to understand about HTTP. First the browser makes its request, and the server listens. Then the server returns its response, and the browser listens. And then the connection is closed. There's no chit-chat back and forth. The browser can do another request immediately after that, but it will be a new request.
Now, the browser is actually pretty limited in what it can do. Through these HTTP requests it gets from the server the HTML code, the CSS code and the Javascript code. It also can get pictures, videos and sound files. And then it can display them according to the HTML and CSS. And Javascript code runs inside the browser and can manipulate the HTML and CSS as needed, to respond to the user's actions. But that's all.
It might seem that the Javascript code that runs inside the browser is all powerful, but that is only an illusion as well. It's actually quite limited, and on purpose. In order to prevent bad webpages from doing bad things, the Javascript in each page is essentially limited to that page only.
Note a few things that it CANNOT do:
It cannot connect to something that doesn't use HTTP. Like an SQL server.
It can make HTTP requests, but only to the same domain as the page (you can get around this via CORS, but that's advanced stuff you don't need to worry about)
It cannot access your hard drive (well, it can if the user explicitly selects a file, but that's it)
It cannot affect other open browser tabs
It cannot access anything in your computer outside the browser
This, by the way, is called "sandboxing" - like, the Javascript code in the browser is only allowed to play in its sandbox, which is the page in which it was loaded.
OK, so here we can see, that accessing your SQL server directly from HTML/CSS/Javascript is impossible.
Fortunately, we still need to talk about the other side of the equation - the web server which responded to the browser's requests and gave it the HTML to display.
It used to be, far back in the early days of the internet, that web servers only returned static files. Those days are long gone. Now we can make the webserver return -- whatever we want. We can write a program that inspects the incoming request from the browser, and then generates the HTML on the fly. Or Javascript. Or CSS. Or images. Or whatever. The good thing about the server side is - we have FULL CONTROL over it. There are no sandboxes, no limits, your program can do anything.
Of course, it can't affect anything directly in the browser - it can only respond to the browsers requests. So to make a useful application, you actually need to coordinate both sides. There's one program running in the browser and one program running on the web server. They talk through HTTP requests and together they accomplish what they need to do. The browser program makes sure to give the user a nice UI, and the server program talks to all the databases and whatnot.
Now, while in browser you're basically limited to just Javascript and the features the browser offers you, on the server side you can choose what web server software and what programming language you use. You can use the same Javascript, or you can go for something like PHP, Java (not the same as Javasctipt!), C#, Ruby, Python, and thousands of others. Each language is different and does things its own way, but at the end of the day what it will do is that it will receive the incoming requests from the browser and generate some sort of output that the browser expects.
So, I hope that this at least gives you some starting point and outlines where to go from here.
First of all there is something that you need to know to do this, and that is the difference between a front-end and a back-end.
Html is a front-end technology, they are called like that because that's what is shown to the user and the back-end it's all mechanisms that run behind the hood.
The thing is, in your front-end you can't do things of back-end, like do querys from a database, manage sessions and that kind of thing.
For that you need a back-end running behind, like php, ruby, node.js or some technology like that.
From the html you can only call functions on the server using things like <form action="/log" method="POST"> this wold call the action /log that you should have already program on your back-end. Don't get confuse with this, there is plenty of ways to sending request to your back-end and this is just one way to do it.
For your specific case I recommend you to look up for ajax, to do the query on your database with no need of the browser to refresh after the query is made.
Some topics you need to know to understand this is:
-what's front-end and back-end and their differences.
-what is client-server architecture
-ajax
-http requests
-how to work with a back-end, doing querys to the database, making routes, etc.
-and for last, wile your server it's not open to the world with your own domain name, what is localhost and how to use it.
I hope that this clarify a bit this, that is no easy thing, but with a bit of research and practice you will accomplish!
I am trying to figure out a way to do an internet connectivity check for an AIR for iOS app. Previously, I was using (against my better judgement) a URLMonitor that checked Google once every 30 seconds. I did not like putting that load onto Google and neither did they; this morning, our network got flagged as a possible DDoS attacker simply from testing the app. So I had to disable this type of check and move on.
I have thought about using the NetworkInfo ANE from Adobe, but that presents its own issues in determining internet connectivity. The only way I can think of doing it is to check for interfaces "en0" and "pdpxx" (which correspond to WiFi and Cellular interfaces, respectively) and check their IPs to ensure they are not in the 192.168.x.x, 10.10.x.x, or 127.0.x.x ranges. However, I am not entirely sure those are the only static router/localhost IPs out there and there is always the possibility that the network interface names will change in the future, which would render this monitor useless. There is also the issue of IPv6 possibly throwing a wrench into this method as well.
Is there another way to check if the user is connected to the internet? I've searched multiple times and it seems that these are the only two ways to check. If that is the case, what is the best way to check?
I'm surprised that you got flagged as a DDoS attacker, are you sure that's what happened?
In any case, if your not happy with putting the load onto someone else's server, then make your own server, just a basic setup that you use with the URLMonitor. You don't have to use google's url with the URLMonitor, you can pass it another URLRequest, which could point to your own server.
monitor = new URLMonitor(new URLRequest("http://www.you-own-server.com"));
This might also be useful if you decide that you want to pass more data between the app and the server. It's your server, so can do what you want with it.
I don't think there's any other way to check if the user is connected to the internet. To be honest, I don't see why there would be. Checking for the users interfaces/wan0 etc... probably would be possible, but you'd need another program, maybe a simple python or c++ program, that Air could use to check these things, but that sounds like the long way round.
I really need your help with this. We are planning on developing a real-time web application. We look at different libraries and concepts and a little confused.
What we need is: clients connect to websites and send data(usually an integer + client machine name) whenever they want (usually 1-5 seconds). Also, the same clients must receive data(the data received from other clients) from the server in a real-time mode. (maximum 0.5 seconds). Also, this data must be stored in the database.
We were thinking about using different technologies, but cannot decide which one to use.
We need this web application to be supported on Iphones and Android Phones (maybe blackberry).
and, of course desktop browsers.
Pooling seems not a very good Idea in this situation, due to highloads.
Html 5 web sockets kinda new, and probably not supported by all browsers.
Have anyone used nodejs ?
or twisted matrix: http://twistedmatrix.com/trac/?
or orbited(cannot post more than one link)?
or tornado?
Or XMPP(Jabber. I did not find good examples.)?
or something else?
What technology is the best to use in this type of project? Also, we would probably prefer the technology that has some community support and free to use.
Thanks a lot!
There is a lot of things to consider here. I would say that HTML 5 is not an option, simply due to support across platform.
Running with NodeJS is most likely possible, but the communication methods are really complicated. Pushing data to a page isn't really something that HTML/web apps are designed to do....
To get a valid answer you are going to need to get someone to come in and sit with you to really iron out details and implementation.
When you say that clients "connect to a website", do you really need it to be a website? It sounds like all the client is sending is a number and for that you don't need a website. Just pick the language of your choice, open up a socket, and go from there.
Are you streaming data to be visualized? You might want to take a look at graphite (and/or "pyped" which is part of graphite).
What kind of data? What is the purpose?
For real-time you're not going to get a web site unless you use some type of RIA but even then, it isn't going to be enough. Services aren't going to be good enough either. You're going to end up doing some type of polling which will only ever be psuedo-real-time unless you do duplex mode which wont be supported on most of the platforms you want to support.
sockets are the way to go but that requires a client for each platform you want to handle. Maybe you should rethink your requirements.
I've been playing with HTML5 location lookups recently and its relatively straightforward to pull someones location from a device like an iPhone.
I want to write an app that uses location data, but its important that the location be factual. In other words I need to prevent people from authoring a fake post to the backing website / web service with mocked up GPS coordinates.
Is there anyway to collect GPS coordinates from a mobile device using the HTML5 geolocation apis and securely transmit that back to a web service in a way that someone wouldn't be able to author a post with the same data and "game the system" so to speak?
Not without some serious encryption on the payload on the client. Which if there is money involved, someone will reverse engineer and figure out how to create valid payloads themselves. Remember if there is money or fame involved then somebody will think the effort to do something like this is "worth it". If your web service is public and not using some kind of encryption nothing on the client will ensure that someone with a network connection can't sniff your protocol and fake whatever data they want. And SSL won't cut it. Anyone can proxy the SSL connection on their local network decrypt the payload and inspect it to their hearts content.
No. Completely agree with the answer from fuzzy lollipop. If you’re talking to a remote machine, the data can always be faked. Always always. What makes you certain you’re even talking to a mobile device at all? The User-Agent string? Pfft, it can be faked. Talking to a GPS? Pfft, could be coming from a predefined path. Talking to a web browser? Pfft, could be a bot, or some other malware.
And don’t think encryption (i.e. HTTPS) is going to help you. The client could edit any of your HTML, CSS, or JavaScript on-the-fly — take Firebug or Greasemonkey for example.
The reasons why you can’t trust the client are the same as the reasons why exploits such as SQL or HTML injection are so common. Ever heard the phrase “the customer is always right”? Well, the customer may be right, but the client is always untrustworthy.
The system is there to be gamed. As flaws are discovered, you patch them one by one. It’s more like leapfrog, rather than achieving the holy grail. Bruce Schneier’s quip “security is a process, not a product” comes to mind. Asking for a system that “can’t be gamed” is missing the point. What you need to be doing is creating a system where the server sanitises the data, and/or rejects bad data — fuzz testing is not a bad idea, either.
That’s about the best you can do without shipping custom untamperable mobiles to your customers with the OS in ROM, and the inside sealed with epoxy.
I want to implement a discrete remote authentication server that handles login for many sites. Somewhat similar to OpenID.
Basically, I have site-1 and site-2 and they're both reliant on the same user database, which is on a separate auth-site. So, auth-site handles user authentication for them, and during this process, makes information on the authenticating user available to the requesting system.
Each site can be on a completely separate domain name, on completely separate machines.
This is all via HTTP(S), there can be no direct database access.
There's one last quirk: once an user has logged in to site-1, when accessing any other site reliant on auth-site, the site must treat the user as already authenticated.
This whole business must be entirely fuss-free to the end-user. It should work like a simple everyday login form.
As a concrete example, say we're talking about stackoverflow.com and serverfault.com, and they both authenticate via authentic-overflow-server-stack.com. Again, once logged in to either site, I can go to the other and do my business without logging in again.
What I'd like to know are the general interaction mechanism between the sites behind this scenario.
In my particular setup, I'm using Rails, but I'm not looking for code[1], just general best practice and guidance, so feel free to answer in pseudo-code or any generally readable language. OTOH, bear in mind that I'll have decent MVC, REST, and meta-programming in my toolkit.
[1]: unless you happen to know an existing tiny neat free MIT/BSD-licensed app/plugin/generator that handles this.
It sounds like (especially with the emphasis on fuss-free), you want something like what the Wikimedia Foundation is doing. Basically, you log on to en.wikipedia.org, then that server communicates with other servers (e.g. en.wikinews.org) and gets authentication tokens. Finally, those tokens are embedded into images, e.g. http://en.wikinews.org/wiki/Special:AutoLogin?token=xxxxxxxxxxxxxxx , and when your browser visits that url (img src) it gets a authentication cookie for Wikinews. Of course, the source code is available for your reivew at http://www.mediawiki.org/wiki/Extension:CentralAuth .
OpenID is also a good choice, but it does require that the user "consciously" visit two domains. An example of one entity with two domains doing this is Canonical. E.g., if you go to https://help.ubuntu.com/community/UserPreferences they will redirect you to Launchpad (https://login.launchpad.net/+openid) for authentication.
Note that Wikipedia is doing this over http, but you can do it all https to ensure the img src tokens aren't intercepted.
Looks like CAS is good enough for me, and has ruby implementations, along with dozens of other lesser languages, e.g. one that rhymes with femoral bone rage.
http://code.google.com/p/rubycas-server/
http://code.google.com/p/rubycas-client/
It sounds like you want to actually use the OpenID protocol itself. There's no reason you can't restrict the authentication provider to only your own server, and do some shortcuts that make the authentication process transparent. Also, the OpenID protocol supports what you describe about logging into one implies logging in to all services.