I wan't developers who embed my webapp to be able to pass a param in the url like ?style=dark which will alter the css accordingly. Is there a better way to keep this setting as the user navigates than appending ?style=dark to all links?
I've considered cookies etc. but if one user is viewing two pages which embed my app with different themes then one will override the other.
I'm using Python/Django.
If you neither want to use Cookies nor Sessions and do not want to embed it into URLs, the only alternatives which comes to my mind are:
First the most generic: Use a dummy domain in front. Instead of www.example.com use h**p://THEME.example.com/PATH. This even works for HTTPS if you own a wildcard SSL for *.example.com.
A second variant would be to create a Basic-Auth-Handler which uses the Theme as the username with a dummy password. The URL then can look like:
h**p://THEME#www.example.com/PATH
However I am NOT sure what happens if a user connects to the same site with two different themes in the Basic-Auth-case. Also it is somewhat tricky to make the site available for search engines if it is behind an authentication handler. This is because you MUST have an auth-handler today to circumvent the Anti-Phishing-protection in modern browsers.
Note that with both methods you can only have one parameter easily. The password does not count and there are browsers out there which do not accept a wildcard SSL cert *.example.com for PARAM1.PARAM2.example.com.
I'm not exactly sure, but anyway you would have to pass this variable to your site. With that I mean, that there is no difference if you add ?style=dark to your href's, or rel="dark" to your <a>'s for use with javascript. keep in mind that it's just an example
Ofcourse you can always work on that AI to predict what the user wanted at the specific moment. hehe
I'm sure you can use a Session for this kind of thing, not? The first time the values are provided via the Querystring you add them to the Session and then retrieve them from the session in the future.
Related
I am trying to pass a value using a link.
For example, if I want to add an email and password for a user to Sign In straight away in the RainLoop webmail.
I am trying using
http://demo.rainloop.net/?RainLoopEmail="new#email.com"&RainLoopPassword="12345"
or
http://demo.rainloop.net/?RainLoopEmail="new#email.com"&RainLoopPassword="12345"#ID
Is this possible to do?
It is possible but you will have to rewrite the rainloop PHP files by yourself. Also parsing passwords via the GET method is a very bad idea. Get commands will stay in your history so everyone who types in
demo.rainloop.net will see the ?RainLoopPassword="12345" also. It's not recommended, but possible. Another safer solution will be using the POST method. I suspect you will use this for you bookmarks or something? You can make an AJAX page which sends a POST request with the username and password to demo.rainloop.net. This way nobody will see your passwords and the effect is the same.
EDIT: For using an AJAX page you have to own a webserver, or register on a free hosting like http://freehostingnoads.net
How exactly does one do something like create a unique URL.
Like how facebook does it facebook.com/mynamehere
One way would be to create multiple folders each time we have a new user..but that doesn't seem to be the best approach
You can try a program like Elgg if you are trying to build a social media site. Otherwise, a person's profile can be custom in a couple of ways. Most of them mentioned. You, as mentioned, can use .htaccess for rewrites. You can use an automated custom url plugin (this may help: How to generate a custom URL from a html input?). Similarly, you can use the previously mentioned Elgg for social media, and but also as a last resort can use your folder method, but only if absolutely required.
I think the question is: how is it done technically, so we don't need to have physical file for every valid URL?
The answer is URL rewriting. In case of Apache server, you want to enable mod_rewrite and configure it to translate particular URL pattern (like myfbclone.com/mynamehere to myfbclone.com/index.php?username=mynamehere). This way you need to have one script file that handles all the URLs accordingly.
Different servers have different means of rewriting URLs, like Nginx or IIS, so the exact way of configuration depends on your server, but the concept is usually the same.
I have a db with a buch of urls. The values were entered by users, so it might be something like www.domain.com or http://www.domain.com or stackoverflow.com or https://something.com
I'm retrieving that data and creating links in a html page so people can click and be redirected to that url.
If i get the url from the page , i'll have either:
1.<a href="www.domain.com">
or
2.<a href="http://www.domain.com">
in the second case it works, but the first it doesn't.
Is there a way to make it always work?
thanks!
The www. bit is not special at all, people rely on an automatic correction feature of most browsers to prepend it if the host does not exist. To replicate this, you need to run a program that attempts to resolve each of the host names in your database, and retries with an extra www. if that fails.
The http:// bit is easy: if it is missing, add it.
There are two ways to handle this situation:
First, validate the user input. At the time a URL is submitted, validate it (preferably on the client side via Javascript) to ensure it has the required elements.
Second, in your code, you can use a regular expression or even simple pattern matching to ensure that the string starts with 'http://' or 'https://', and prepend it as needed.
The implementation details vary from language to language, but the concept is the same.
I was wondering how to keep images secure on my website. We have a site that requires login then then user can view thousands of different images all named after their ID in the database.
Even though you need to login to view the images the proper way...nothing is stopping a user from browsing through the images by typing <website-director>/image-folder/11232.jpg or something.
this is not the end of the world but definitely not ideal. I see that to stop this facebook just names the images something much more complicated + stores them in hashed folders.
Gmail does a very interesting thing, their image tags looks like this:
<img src=/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5>
I thought the src attribute has to contain a reference to an image??...how does gmail get around this?
This is more for educational purposes at this point, as I think this gmail scheme might be overkill for our implementation.
Thanks for your feedback in advance,
Andrew
I thought the src attribute has to contain a reference to an image?
GMail is referencing an image. It's just being pulled dynamically, probably based off of that th=12d7d49120a940e5 string.
Try browsing to http://mail.google.com/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5
Instead of it being a direct path to its location on the server's filesystem, it uses a dynamic script (the images may even be in a database, who knows).
Besides serving up an image dynamically from your webapp, it's also possible to use a webapp to dynamically authorize access to static resources that the webserver will serve -- commonly by putting the files somewhere that the webserver has access to, but not mapped to any public URI, and then using something like X-Sendfile (lighttpd, Apache with mod_sendfile, others), X-Accel-Redirect (nginx), X-Reproxy-File (Perlbal), etc. etc. Or with FastCGI you can configure an application in a FastCGI "authorizer" role rather than a content provider.
Any of these will let you check the image being authorized, and the user's session, and make whatever decision you need to, without tying up a proceses of your backend application for the entire time that the image is being sent to the client. It's not universally true, but usually a connection to the backend app represents a lot more resources being reserved than a connection to the webserver, so freeing them up ASAP is smart.
The code that runs after this GET request is issued:
/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5
outputs an image to the browser. Something doesn't have to be named with a .jpg or .png or whatever ending to be considered an image by a browser. This is how captcha algorithms are able to serve up different images depending on a value in the id. For example, this link:
http://www.google.com/recaptcha/api/image?c=03AHJ_VusfT0XgPXYUae-4RQX2qJ98iyf_N-LjX3sAwm2tv1cxWGe8pkNqGghQKBbRjM9wQpI1lFM-gJnK0Q8G3Nirwkec-nY8Jqtl9rwEvVZ2EoPlwZrmjkHT7SM32cCE8PLYXWMpEOZr5Uo6cIXz1mWFsz5Qad1iwA
Serves up this image:
So the answer really is to just obfuscate your image names/links a bit like Facebook does so that people can't easily guess them.
It's an important security issue and I'm sure this should be possible.
A simple example:
You run a community portal. Users are registered and upload their pictures.
Your application gives security rules whenever a picture is allowed to be displayed. For example users must be friends on each sides by the system, in order that you can view someone else's uploaded pictures.
Here comes the problem: it is possible that someone crawls the image directories of your server. But you want to protect your users from such attacks.
If it's possible to put the binary data of an image directly into the HTML markup, you can restrict the user access of your image dirs to the user and group your web application runs of and pass the image data to your Apache user and group directly in the HTML.
The only possible weakness then is the password of the user that your web app runs as.
Is there already a possibility?
There are other (better) ways, described in other answers, to secure your files, but yes it is possible to embed the image in your html.
Use the <img> tag this way:
<img src="data:image/gif;base64,xxxxxxxxxxxxx...">
Where the xxxxx... part is a base64 encoding of gif image data.
If I needed security on my images directory I wouldn't expose the directory at all. Instead my img src attributes would reference a page that would take a userid and an image id as a parameter.
The page would validate that that user did indeed have access to see that picture. If everythings good, send the binary back. Otherwise send nothing.
for example:
<img src="imgaccess.php?userid=1111&imgid=223423" />
Also, I wouldn't use guessable id's. Instead sticking to something like base 64 encoded guid's.
I'm not sure I understand, but here goes. Instead of serving up static images that reside in an images folder - why couldn't you, using your server side technology of choice, have the images dynamically sent down to the client? That way your server side code can get in the mix and allow or deny access programmatically?
<img src="/images/getImage.aspx?id=123353 />
You could move the pictures out of the document root into a private directory and deliver them through your application, which has access to that directory. Each time your app generates an image tag, it then also generates a short-lived security token which must be specified when accessing a particular image:
<img src="/app/getImage.xyz?image=12345&token=12a342e32b321" />
Chances are very rare that someone will brute force the right token at the right time with the right image.
There are at least to possibilities to verify the token in "getImage":
Track all image tags in your app and store records in a database which link the randomly generated tokens and image IDs to the requesting users. The "getImage" action then checks the supplied parameters against that database.
Generate the token as a checksum (MD5, CRC, whatever) over the user ID, the image ID and maybe the current day of the year, and be sure to mix in an unguessable salt. The "getImage" action will then recompute the checksum und check it against the specified one in order to verify the user's access. This method will produce less overhead than the first one.
PHP example:
$token = md5($_SESSION['user_id'].' '.$imageID.' '.$SECRET_SALT.' '.date('z'));
With HTML5 you could use the canvas tag and JavaScript to do this.
You could perhaps do something with either CSS or a table layout to draw a picture (probably really bad performance, resolution, portability).
Either way, there is no stopping people from taking your pics. They could take a screenshot and crop it out.
As Chris mentioned in his answer, having long picture id's so that the URL for each image is not easy to guess or brute force is important. And no directory listing on your webserver directories is also.
https://www.base64-image.de/
I used this website to generate base64 code fir given image, and then this website provide code to directly paste . It worked.