Javascript使用加密参数转到URL

Question

I am creating a google chrome extension which works and looks as if it was an extension of my website.

When you first open my extension you would have to login. When you enter your username and password an ajax request is sent to my server. If the result of the username and password is true i encrypt the password and store it in the extensteion

Now here is where it gets tricky:

if the user goes to my website it should automaticly log him/her in. i thought that i would in my extension make a check that if the website was mine it would redirect to a suburl and send the encrypted password / username, and my site would then auto log the user in

An example of an encrypted password looks like this: ZNVwb7ukhJfhBmdbo4SkPMjG6U8a0GKQB+/mPhQtRVw=

because of / i would like to send it as a post request.

Do you guys know how i would achieve this?

Answer 1

Without commenting on the encryption you are using, it sounds like you want to avoid a GET request solely because the URL contains the / character?

You can send this via GET, you should simply URL encode the value.

URLs can only be sent over the Internet using the ASCII character-set.

Since URLs often contain characters outside the ASCII set, the URL has to be converted into a valid ASCII format.

URL encoding replaces unsafe ASCII characters with a "%" followed by two hexadecimal digits. URLs cannot contain spaces. URL encoding normally replaces a space with a plus (+) sign or with %20.

So if you want to send a forward slash to be interpreted as a query string parameter instead of a path delimiter, you should encode it to %2F . It is better to use a standard library for this and pass the whole string in rather than rolling your own to only encode the slash.

Answer 2

I would suggest rather than trying to store an encrypted password and possibly succumbing to future security issues, you use a token instead. So the process would be:

• The user runs your extension
• The extension sends the user's login information to the remote server (over HTTPS) and gets back a token
• The token is used for all further requests

To do this you need a session table on your remote server that can interpret the token in each request to find the user that is making the request. Best practice would dictate that eventually the token should become stale with inactivity, requiring a user to login again. This time out would generally be in the range or 1-24 hours.