a way to encrypt URL?

is there a way i can encrypt a page URL so that no one can access the page by typing it in the address bar?

 

I'm sorry I have no idea but I'm awfully curious as to why you'd want to do that.

Lisa

 

do you want that it should show a blank page when typed in the address bar or nothing at all ?

 

You could simply password-protect the site ;-)

From the protocal side there is no definitive difference between requests made by people typing a url into their browser or clicking on a link. You would probably have to tell us what you intend to do, perhaps someone has a solution for you.

 

lol...

 

i want only certain people who has , say , paid fees to access the secret area. immediately (as opposed to me manually looking at their receipt and givig them the link).

 

Ok, to accomplish that you normally generate a url with an encrypted parameter that identifies the user. You could e.g. encrypt the users email-address with a key only known by you and put that into the url. Your website can then check if the parameters fit and give acccess to the content.

 

If you're using PHP it's very easy to do something that would prevent users from accesing content they're not supposed to.

For example, you can create a function IsUserLoggedIn() that would read two cookies stored on the user's computer, containing the account number and a password hash.

At the very top of each page that should be restricted, you can insert something like this :

For a bogus page : http://www.foobar.net/private_area/index.php

<?
require_once("file_where_function_is_stored.php");

if (IsUserLoggedIn()==false) 
 { header("Location: http://www.foobar.net/private_area/login.php");
   die();
 }
// if user has the two cookies and they're valid, he's logged in and can access info
?>

PHP:

 

Hi Devin09 - no problem, I do this kind of thing all the time. EZ & works great. Let's say you want to encode something like this:

?a=123&b=456

Use some encryption class or, if you're not super anal, base64_encode it like this:

$p = base64_encode($a.'|'.$b);

Then use this for your URL:

?p=xxxxxxxxx (whatever the above encodes to)

Then it's just as easy to decode it:

$params = explode('|', base64_decode($_GET['p']));
$a = $params[0];
$b = $params[1];

Obviously this example is with PHP.

 

thanks guys for the suggestions. guess i'll have to bring these suggestions to someone who knows PHP.

 

I already know he's going to use base64, because it's great for this kind off purposes.

 

Base-64 is not encryption in any way. Anyone attempting to crack security will know of base64_decode. This kind of security is almost as secure as no security.

 

Messing with the address is absolutely not what you want. There is no point in it. If you encrypt the address, how in hell will the dns figure out where to send your visitor? How will even the visitor you want enter the address?

At the basic level, you want authentification, authorization and access control. These are straight forward web server functions. RTFM. You can go further with server side scripting (these functions are never handled client side), right up to secure socket layers, ssl, and encrypted communication.

Further questions would belong on a web server forum/list, or on one dedicated to the language of choice.

cheers,

gary

 

@kk5st:
Of course he doesn't want to mess with dns, but none of the other posters recommended that?
And building a clickable url with some kind of encrypted string is probably more intuitive for his customers than giving them a username/password login and http auth - though that would technically be the nicer solution.

 

There is no sane reason to encrypt or even obfuscate a url. If you want to limit access to a site, a directory or even a single page, you must have some way to authenticate the user. Once authority to visit has been established, and if security is not a high priority, the requested page could read previously set cookies and allow immediate access. No cookie, no login, no access. In no case does hiding the address mean a damned thing.

It's not rocket science, people. Read the reference I posted and make your list of people authorized to access the page(s).

gary

 

Of course http auth is not complicated to setup.
But building a url that contains e.g. a username and an encrypted variant of the username (I mean encrypted - not base64'd) is much more convenient for the user and should be enough security for mosts cases.

 

How is it more convenient for the user? They would still need to enter their user ID and a password at some point, and the restricted section should still operate in exactly the same way once they are authenticated; the experience should be the same for the user either way. The difference is for the developer: which method is easier to implement, which method is easier to maintain, and which method is secure and reliable?

 

I must be missing something really important here. How is the user to construct a url containing the encrypted username, &c. Is it to be included in the link to the restricted page? Then how is not everyone able to use it? No! At some point the user must be authenticated as having authorization to access the page.

How hard is this on the user?

1. user: Clicks on link to restricted page.
   
   
2. server: Returns 401 Unauthorized — The request requires user authentication.
   
   
3. browser: Asks for username and password.
   
   
4. user: Fills in the username and password and submits.
   
   
5. server: Validates and if OK, sends page.
   
   
6. browser: Handles automagically from that point 'til end of session.

[edit] I dithered while FeelLikeANut answered [/edit]

gary

 

Perhaps I have the wrong starting point here: I suspect that the user is buying something (like a pdf download) and as a result gets an access link via email. Of course if he will get access to more than a download - like a complete member area - a full-featured login either via http auth or some kind of session-based stuff is better. At least password-protection was my first suggestion in this thread ;-)

 

Yes, yes it was, and props for that. But then you went nutty on us

The OP, in your scenario, can 1: auto-generate email to the user with a username/password; or 2: generate the username/password on the receipt page. Either way, the backend generates the authorization file entry, and either way the authority can be time limited or use limited. It's all backend stuff.

cheers,

gary