just naturally inquisitive here. and that abuse concerns newbies only? they don't pose a threat when they become junior members?Originally Posted by diem
just wondering, really. no need for explanations or answers.
just naturally inquisitive here. and that abuse concerns newbies only? they don't pose a threat when they become junior members?Originally Posted by diem
just wondering, really. no need for explanations or answers.
As previously stated, you don't need to know about it. This isn't the thread for "fishing expeditions".
Best Regards
I will just google it, sir Beor.
well, just glad to have something made clear. thanks.
One abuse i can think of SQL Injection. But this wouldn't happen if queries are not using bind parameters.... which is easy to fix. Well of course it also depends on the code if it is not BOTYOK.
Exploits are there if you FAIL to address the problem. Using the search function doesn't constitute an abuse. This is a free membership forum. That is the reason why the Search button is invented.
I doubt somebody would D.O.S. this site. I'll be shocked
You can NEVER say that your web app is already 100% tuned or optimized if major problems exist.
One solution I can think of is having an indexer program that runs every night. Probably in the wee hours so that the activity is at its minimum.
Then port your search function to use the indexed data. And by the time the a user hits the search button, VIOLA!. Less than a second and it can already return a result.
So it is still a caching/indexing solution.
But a simple solution would be is to limit the number of search operation of a user per day and address SQL injection problem (if that exists).
-my two cents on how to improve this site.
Guys. What do you think?
Thanks for your suggestions.. but really though, SMF is a solid platform and the possible flaws that you have mentioned is virtually non-existent... unless you still haven't figured out what we are using... and as you stated, DDOS is far-fetched.
We are already using custom indexes which is more than twice the size of our actual db so that's not an option anymore. Caching.. you can check the bottom part of the page and see how long it takes to create a page... again, unless you have an idea about the difference of a cached system and not you will fail to notice it.
What I can probably do is add a Google sitesearch when I have time. That's the best I can do for now.
Best Regards
Ok. thanks for the insight bro. appreciated.![]()
I'm going to jump around here from issue to issue ... so consider this a long run-on sentence.
First off, 40 posts is nothing. We choose to reward those who stick around istorya instead of one post wonders. That is a choice that has been made which no amount of argument can change. Secondly, iSTORYA is free, any amount of performance we can squeeze out of the system without compromising the general experience is a no brainer. I don't even know why you bring up SQL injection since it is not even an issue in regards to search or performance. Third, if you wish to search istorya without waiting, simple google ...
SEARCH_QUERY site:www.istorya.net/forums
... replace SEARCH_QUERY with whatever you wish to search for.
You ask for what kind of abuse that might occur if the search was open for all ... here are just a couple ... splogs, abusive spiders.
iSTORYA already implements caching.
Best case scenario is not the best case scenario. Searches are not the best use for a caching system. Pages are ... main topic -> subtopic -> specific topic -> page no. With data being pulled from the cache, we have less queries to the DB.Best case scenario - 2 operations (search, click page no.)
Worst case scenario - x operations. (main topic -> subtopic -> specific topic ->...-> page no.)
Limiting the number of searches users can do punishes everyone and doesn't make anyone new do anything to receive a privilege.
That is all.
Similar Threads |
|