Security matter: are parameters in url secure?

I have developed myself in the last few months about web development in java (开发者_高级运维servlets and jsp). I am developing a web server, which is mainly serving for an application. Actually it is running on google app engine. My concern is, although I am using SSL connections, sending parameters in the URL (e.g. https://www.xyz.com/server?password=1234&username=uname) may not be secure. Should I use another way or is it really secure? I don't know if this url is delivered as plaint text as whole (with the parameters)?

Any help would be appreciated!

Everything is encrypted, including the URL and its parameters. You might still avoid them because they might be stored in server-side logs and in the browser history, though.

Your problem seems to go further than Web Server and Google App Engine.

Sending a password through a web form to your server is a very common security issue. See this SO threads:

• Is either GET or POST more secure than the other? (meaningly, POST will simply not display the parameter in the URL so this is not enough)
• Are https URLs encrypted? (describes something similar to what you intend to do)

The complete HTTP request including the request line is encrypted inside SSL.

Example http request for the above URL which will all be contained within the SSL tunnel:

GET /server?password=1234&username=uname HTTP/1.1
Host: www.xyz.com
...

It is possible though that your application will log the requested URL, as this contains the users password this may not be OK.

Well, apart from the issues to do with logging and visibility of URLs (i.e., what happens before and after the secure communication) both GET and POST are equally secure; there is very little information that is exchanged before the encrypted channel is established, not even the first line of the HTTP protocol. But that doesn't mean you should use GET for this.

The issue is that logging in is changing the state of the server and should not be repeated without the user getting properly notified that this is happening (to prevent surprises with Javascript). The state that is being changed is of the user session information on the server, because what logging in does is associate a verified identity with that session. Because it is a (significant) change of state, the operation should not be done by GET; while you could do it by PUT technically, POST is better because of the non-idempotency assumptions associated with it (which in turn encourages browsers to pop up a warning dialog).