Develop Reference

Javascript Client Authentication (with SSL, without OAuth2)?

The scenario is:
I have a web API, which is being accessed by two clients:
Web App written in Javascript, which is minified
iOS App
SSL is all set up on the server hosting the API, and it works fine. There is no User Auth for the API because it's a sort of location-based searching app.
I want to ensure though that only the web app and the iPhone client are able to actually make requests to the API. For the iPhone client it's easy - a shared secret between the server and the app will do, and it's encrypted with SSL so we're not worried about people spying on it.
But for the web app the same solution won't work. I can't just leave a string in the code, and even if it's encrypted in there that's all somebody would need.
Basically, I'm looking for a good solution to this problem. I just want to make sure it's kept only to clients who are allowed to use it, but I'm not sure how I can without going and implementing OAuth which I think is probably overkill. Any ideas?
Thanks!
Dan

It can't be done. Even with oauth. Even assuming that your iOS app is secure, is wrong: it can be decompiled. Any code that runs on the client, can be tampered with, and can't be trusted to be who he says he is.
Only question is: is the API you provide valuable enough, and how much trouble would someone want to go through to hack it. And how hard do you want to make it for whomever wants to hack it.
The iOS version is indeed way safer than the javascript version. In the webapp you can obfuscate your code to make it harder to hack. You can (if you don't intend to use it on iOS) use java or flash to further hide your signing code (HMAC-sign your requests, don't just send a shared secret with them. You may think SSL is secure, but there is a moment before the url is encrypted....).
The way the "big guys" deal with this is:
Whatever you build, assume that someone will be able to hack it (as in: use your API for some other purpose than you intended).
Think about how bad this really is (note: they wouldn't be able to build a business on it; it would be WAY TOO vulnerable to lawsuits). Is it really the end of the world if a lone wolf uses your API.
If you do care about the lone wolves, make it as hard as possible (but honestly, isn't it cheaper just to loose some money from the lone wolves, than to spend 2 developer-months on it?)
If somehow there is serious interest in hacking into your API, try to come to an understanding with the hackers (e.g. I like the way how Spotify reacted to despotify. Basically they said "hey, if you don't release anything that makes it really easy to steal our music or circumvent our businessmodel, we won't try too hard to block you")

Is there anyway to do port discover from Javascript in an intranet web application?

Say I wanted to write a local web server that listened on a random port.
Now I want to write HTML that works in most browsers that can do AJAX calls to it.
Is there any fundamental limitation here?
EDIT: I've confused people - probably because this is almost the first time I've ever posted with the javascript tag and I don't have a feel for how to ask questions.
I recently became aware of node.js - which I didn't learn more than it makes writing stand alone web servers easy to implement.
Then I had the vision of a site sort of like this one (any programming board really) but where code samples could execute on end users local machine. I don't like browser plugins at all though, so I started trying to think of a way to make it happen with minimal knowledge between the web/browser part and the local machine's service (there has to be interaction - i just wanted to think of the minimal amount).
And that is just an example - really I write intranet business apps for a living (in which case defining well known ports is easier so I don't need an answer to this question for that purpose..)

The same origin policy will prevent you from accessing other ports (at least in most browsers), but you I guess you could send JSONP requests to every port on localhost, and then catch the port that gives a valid response.
...If you really wanted to, that is. There is a lot of valid ports, so it could take some time.

GWT server with get() and post() built on client end

This is more of a curiosity really, to see if some one has done anything similar, or if at all it is possible.
I'm working on a project that will get notification through external notifications. Now I could go about doing this by having notifications coming to my server and have a comet setup between my client and server.
BUT
I was wondering if I could write server logic into my client and listen out for notifications from external sources. Immediately one issue I see is, external sources would need callback URL etc, which I dont know if you could do from client side (unless one could use the IP address in that way).
As you can see it is more ideas and discussions if such a thing was possible, this is somewhat inspired by P2P models whereby you wouldn't be mediating things through your central server.
Thanks in advance!

GWT compiles (nearly) Java source into JavaScript, so compiled GWT apps can't do anything that traditional JavaScript running in the browser cannot do. The major advantage of bringing Java into the picture isn't automatic access to any/all JVM classes, but the ability to not only maintain Java sources, which tend to be easier to refactor and test as well as keep consistent with the server, and to compile that statically defined code into JavaScript, performing all kinds of optimizations at compile time that aren't possible for normal JavaScript.
So no, while you can have some code shared by the client (in a browser) and the server (running in a JVM), you can't run Tomcat/Jetty/etc in the browser just by using GWT to compile the java code into JS.
As you point out, even if this was possible, it would be difficult to get different clients to talk back and forth, without also requiring that the browsers can see and connect at will to one another. BitTorrent and Skype have different ways for facilitating this, and currently browsers do not allow anything like this - they are designed to make connections to other servers, not to allow connections to be made to them.
Push notifications from the web server to the browser are probably the best way forward, either through wrapping comet or the like, or through an existing GWT library like Atmosphere (see https://github.com/Atmosphere/atmosphere/tree/master/samples/gwt-demo for a demo).

Creating a fully functional website while only using vanilla coding

When I say "Vanilla Coding", I am referring to websites that don't utilize server side coding (such as PHP, ASP, etc.), only HTML, JavaScript, and CSS.
I know that there are a plethora of sites that already exist that don't utilize (to my knowledge) any of the common, server side languages used by many others (PHP, ASP, etc.), but still function just fine!
I am confused! How do these sites continue to save login information, keep records, etc. etc. without using a server side scripting language? Is there something that I am missing? Can JavaScript access more (such as databases and local files) than what I thought it could?
EDIT
Turns out I've made a serious and shameful mistake in assuming that just because it ended with a .html extension that it was client-side only. That is okay though because I'm learning. Thanks so much for the help everybody!

Essentially, unless you have some sort of server-side programming, you don't stand a chance at making a site with any amount of functionality. To break it down for you:
What you can do without server-side scripting:
Serve static pages
What you need server-side scripting for:
Absolutely everything else
Even something so simple as keeping a site consistent and up to date is a nightmare on wheels without, at the very least, some some sort of management system that pre-generates the static pages to be served. (Technically, one could argue that Copy+Paste in Notepad counts as this.)
As has been mentioned elsewhere; obfuscating the true nature of precisely what system is being used is trivial; and having URLs ending in, say, .html while using PHP is no issue.
Edit: In the most perverse case I can think of off the top of my head, you could have a lighttpd server masquerading as an IIS server, serving pages generated by an offline renderer fed to it by a Perl FastCGI script, sent together with PHP signature heading and using a mix of .asp and .jsp file extensions.
Of course, noone would do something as silly as that. I think…

No client side script can access server side information (like a database) without some sort of server side communication (through something like ajax or the like)
If you really ( i mean really as in don't do it ) want to do logins and the like on clients side, you would have to make some sort of cookie that you store on the user's computer, also you would need a list of users (which anyone can read) to use against

This answer is very late but I leave this reply for anyone who may stumble upon it.
Using javascript/jQuery, and various APIs a simple site can be created only using client-side coding.
For instance, a simple shopping cart type of site can be created. I've done it before.
There are few (not many) strictly 100% jQuery based shopping cart solutions that are open-source.
How does the PG (pay gateway) get taken care of? You are limited to accepting payment through paypal, google checkout, and direct deposit.
What about allowing customers to leave comment? You can use API's like Disqus. What about chat support? Zopim is pretty handy.
How do you get notified when purchase is made? Paypal & google checkout notifies you.
What about sending mass email? Mail Chimp.
Personally, I almost always use WordPress or some other types of CMS but using only vanilla coding to build a simple site is not only feasible but very sensible in certain circumstances.

You're not going to see whether a site is using a server side language unless they let you see the file extensions. With URL rewriting, MVC patterns, etc., it's easy to hide, or even fake that information. Therefore, chances are very good that the sites that you think aren't using a server side language are actually using one.
Now, a site can save certain information in cookies, such as some basic preferences, but any authentication they appear to be doing wouldn't actually be doing anything without a server-side script accessing a database somewhere.
As a side note - I have worked on a site where the content was actually static, but made to look like a blog or CMS. It was an absolute nightmare and hugely error-prone.
What are these sites that you think aren't using server-side scripting?

Nowadays a lot of sites are using Javascript as a server side solution, Node.js being the most popular. Check out this list: https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node

Webserver virtual network

It's quite hard for me to figure out if this sort of thing has ever been implemented. I want to look for any libraries that may exist so I don't go about reinventing the wheel.
I have this idea of having a web app that connects the people who are on the site. Every user that is connected to the site may communicate to another user also on the site via the server. So the protocols will be implemented in JavaScript, and the server simply helps to identify users, and just echoes data to enable the communication. For instance I can use this to implement my game networking ideas in javascript, and easily test them without having my testers download any executables, they can just log onto the site.
Now obviously this isn't going to be an effective architecture for any kind of serious application. But I think if I can get it working I could build really cool networking apps without having any sort of download.
What I'm thinking about is using ajax for client->webserver and webserver->client (Comet?) and I can code up the webserver echo bit with PHP or a cgi script. And then I can implement an entirely separate protocol in JS that the webserver does not care or know about.
The reason for having the webserver echo everything is because I don't want to use java or anything else that I can open up sockets in. Why make it harder for me? Because I can and because I happen to be really enamored with javascript at the moment. It's the only web technology I trust. Screw java applets.
Does this make any sense to anyone? Am I crazy?

Don't know about the crazy part (there's a proposal at area51, go check that) but it's definitely doable.
You could use a plain old XMPP server and a javascript XMPP client (there are libraries - for example strophe)
You could do it with AJAX and a PHP backend: Making an AJAX Web Chat
You could use the fancy Websockets from HTML5: Start Using HTML5 WebSockets
You could use some existing component if you can find any (I couldn't find any I would use)
Cheers :)