• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Passing Special Characters via url w/o encoding

T

TechBoyJK

Lifer
Hi Guys,

I'm pretty sure this isn't possible.

I'm working on an API and for our remote user registration function (passed via http), the password the user wants needs to be included. We don't keep the password, we hash them. And this will all be sent over https so that the passwords are encrypted and not sent via clear text.

I WANT users to user cryptic passwords, so we welcome passwords with special characters including those that would break a URL. I'm ok with having to accept that if a password with special characters is sent, it needs to be encoded for URL format (and decoded at the server), but I was curious if there is a way around it.

Example:

https://company.com/myfunction.cfc?createUser&userName=myUser&email=johndoe@outlook.com@password=wysiwyg$#@!&*
 
Every http client out there (except for the ones that nobody uses. IE the really crappy homebrew stuff). supports at least GET and POST. If you are lucky, the client might support DELETE and PUT as well (Thus, your restful application can be born).

GET should never be used for sending passwords. It is just a bad idea.
 
besides the fact that you said you will hash it. then the specially characters will be hashed too and hence "encoded". But yeah, use POST.
 
Hashes are not secure, they are an obscuring algorithm that delays someone finding a password for a few hours to days at most. If you are going to send them around make sure you do so within real encryption.
 
BrightCandle said:
Hashes are not secure, they are an obscuring algorithm that delays someone finding a password for a few hours to days at most. If you are going to send them around make sure you do so within real encryption.
Click to expand...

This is just not true. Hashes are not just obscuring algorithms.
 
BrightCandle said:
Hashes are not secure, they are an obscuring algorithm that delays someone finding a password for a few hours to days at most. If you are going to send them around make sure you do so within real encryption.
Click to expand...

Ummm.... no... It may be trivial to find a collision with a week hash, but it certainly doesn't mean that hashing in general isn't secure.

Strong crypographic hashes with some salt are next to impossible to find collisions. It will be a while before SHA-256 is broken
 
BrightCandle said:
Hashes are not secure, they are an obscuring algorithm that delays someone finding a password for a few hours to days at most. If you are going to send them around make sure you do so within real encryption.
Click to expand...

SSL. I don't care what format you send the data down the wire, it's encrypted the whole way anyways.
 
beginner99 said:
besides the fact that you said you will hash it. then the specially characters will be hashed too and hence "encoded". But yeah, use POST.
Click to expand...

I'll be using SSL (as I said in the OP).

The hashing occurs AFTER the data is sent. So the actual pw would need to be included.

Once it gets to the server, I use SHA 512 to create the hash and I salt it as well. I only keep the salted hash and discard the pw after it's created. I could let API access salt it on the client side, but I don't want to put that process in the hands of a 3rd party.
 
TechBoyJK said:
I'll be using SSL (as I said in the OP).

The hashing occurs AFTER the data is sent. So the actual pw would need to be included.

Once it gets to the server, I use SHA 512 to create the hash and I salt it as well. I only keep the salted hash and discard the pw after it's created. I could let API access salt it on the client side, but I don't want to put that process in the hands of a 3rd party.
Click to expand...

Ok, SSL + POST. I would say that is done on most login pages...
 
TechBoyJK said:
This isn't for webpages. This is for external apps.

I've already programmed the sites login page to use SSL and post. This is for something different.
Click to expand...

which doesn't change anything. Use POST instead of GET. Whatever the http client is (browser, curl,...) does not really matter.

Else web application frameworks or pgoramming languages usually have a function to deal with url encoding. In php it's urlencode.
 
TechBoyJK said:
This isn't for webpages. This is for external apps.

I've already programmed the sites login page to use SSL and post. This is for something different.
Click to expand...

To be quite frank, this is a pretty basic API design paradigm. Have you read any resources regarding API design before you started this?

The above posters are correct. Generally you want to use a POST when "creating" an object through a service call. This has nothing to do with web pages. POST is a request method supported by HTTP.

For example, a popular iOS networking library is called AFNetworking. If you wanted to create a user in your app, you might do something like:

Code: 
    NSURL *url = [NSURL URLWithString:@"https://api.mysite.com"];
    AFHTTPClient *httpClient = [[AFHTTPClient alloc] initWithBaseURL:url];
    
    NSDictionary *params = [NSDictionary dictionary];
    [params setValue:@"password123" forKey:@"password"];
    [params setValue:@"bob@test.com" forKey:@"username"];
    
    NSMutableURLRequest *request = [httpClient requestWithMethod:@"POST" path:@"/user" parameters:params];
...
 
mosco said:
To be quite frank, this is a pretty basic API design paradigm. Have you read any resources regarding API design before you started this?

The above posters are correct. Generally you want to use a POST when "creating" an object through a service call. This has nothing to do with web pages. POST is a request method supported by HTTP.

For example, a popular iOS networking library is called AFNetworking. If you wanted to create a user in your app, you might do something like:

Code: 
    NSURL *url = [NSURL URLWithString:@"https://api.mysite.com"];
    AFHTTPClient *httpClient = [[AFHTTPClient alloc] initWithBaseURL:url];
    
    NSDictionary *params = [NSDictionary dictionary];
    [params setValue:@"password123" forKey:@"password"];
    [params setValue:@"bob@test.com" forKey:@"username"];
    
    NSMutableURLRequest *request = [httpClient requestWithMethod:@"POST" path:@"/user" parameters:params];
...
Click to expand...

To be more semantic, you should use a POST request when the request will alter state on the server. A GET should be used for requests that retrieve data. A PUT request should be used when a client wants to store information on the server, and a DELETE request when the client wants to remove data from the server.
 
Crusty said:
To be more semantic, you should use a POST request when the request will alter state on the server. A GET should be used for requests that retrieve data. A PUT request should be used when a client wants to store information on the server, and a DELETE request when the client wants to remove data from the server.
Click to expand...

PUT can be used to "alter state on the server". PUT isn't just for storing information, but can also be used to update objects that were created with a POST.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top