I'm working on a MediaWiki plugin that adds a certain captcha if users have more than three bad login attempts. I'm basing this on the existing ConfirmEdit plugin but for some reason the way they store bad login attempts doesn't seem to work for me. After checking the code they use, it seems they're using the global variable $wgMemc, which in my case appears to be an instance of FakeMemchachedClient. This is a fake memchache that just returns true on everything without even saving anything.
I'm trying to find out how to implement another way to internally keep track of the amount of bad logins, preferrably without having to consult the database for this.
The only thing I could come up with that avoids the cache entirely is POSTing the amount of bad logins, but this could easily be modified by a smart user/bot...
Anyone have any ideas?
In ideal case, $wgMemc should be instance of MemcachedPhpBagOStuff. It is actually an interface to memcached, see the MediaWiki page about it for more information and usage in MediaWiki.
For this use case it would be great choice. However, since it seems you don’t have memcached set up, the only viable alternative is probably using the database.
Related
I have a very-simple php-based website.
I would like to add "subsribe for information" box and send it to some list-management tool.
I found that phplist is quite a good one. However, I don't find any api which allows me to subscribe users using ajax.
(I would like to avoid the pages of phplist in order to avoid confusion due to different design, and also I want the interface to be multi-language).
Of-course I can touch the code, but I doubt that it misses this feature, so I assunme I simply missed it.
Thanks!
Hopefully you have managed how to achieve this already. I have a different use case not requiring AJAX.
Anyway, I've found a script that tries to ease the addition of subscribers to your list. Maybe you could use it as the backend to support your AJAX request.
This is the thread in which the script is shared, as others have found it useful, also for unsuscribing users, even handling massive subscriptions/unsuscriptions:
http://forums.phplist.com/viewtopic.php?t=5009
Finally, be aware this code is using PEAR DB abstraction layer, probably I'm going to use this but without the PEAR package.
I look forward for what you could do through AJAX and this functions.
I'm just getting started with ImageResizer and I'm stuck on what seem like totally basic questions:
I have an uploader that I use to put images into a directory that's not directly accessible over HTTP. (If I just put a image at, say, /images/myimage.jpg, then anyone could access it by just asking for it, whereas I want to limit access via thumbnails, watermarks, etc.). So I want to put it at /offlimits/myimage.jpg, but be able to serve it up at /public/images/myimage.jpg.
I don't really want to dump all the images in the same offlimits folder, because putting lots of files in one folder makes Windows unhappy. But I don't want to expose the details of that subdirectory structure either, so where do I put the mapping between the public facing url and the actual image location?
Most generally, I don't necessarily want an image extension at all, so I'd like to say /public/image_id?width=100... and have this map to /offlimits/sub1/sub2/sub3/image_id.jpg.
Can anyone advise about how to set this up?
Three part questions are generally frowned upon here at SO, but I'll bite anyhow :)
If you're allowing access to images based on authentication, then you need to use ASP.NET's URL Authorization feature. ImageResizer supports URL Authorization rules. If you just don't want the source files available, and want to force them resized or watermarked, read the docs on how to implement arbitrary rules like this.
You can rewrite image paths to your heart's content with Config.Current.Rewrite, which works just like the PostRewrite event mentioned earlier. Just remember you'll have to keep it all straight in your head later.
Image extensions are good things. Don't fight them. They let the server figure out the right mime-type to send and help errant browsers recover from related bugs. They prevent issues on several platforms and make the Save As dialog work. They significantly improve server efficiency as well, since handling logic doesn't have wait as long. This is particularly relevant because of the design of the IIS/ASP.NET modules system.
Is there a risk in using #Html.Raw? It seems to me there shouldn't be. If there is a risk then wouldn't that risk already exist regardless of using #Html.Raw in that modern browsers such as Chrome will allow an edit injection of <script>malicious()</script> or even to change a form's post action to something else.
#Html.Raw will allow executing any script that is on the value to display. If you want to prevent that you need to use #Html.AttributeEncode
Correct, the risk is in how it is used. There's no risk inherent in Html.Raw. It's a tool, nothing more.
If you are displaying user entered information it is better to use #Html.Encode().
In another words, if you are displaying non-user eneterd data you are safe to go with #Html.Raw()
So I have a framework we've built on codeigniter. It uses regular codeigniter sessions by default which allows up to 4kb storage encrypted on a cookie.
Its for general apps that require a registration process, which can vary in size as questions are generated dynamically through an admin panel. Registration process relies on session data as it redirects throughout process.
I have used db_sessions in the past when I knew this would be an issue on the framework, however, I'm now considering the possibility to always have registration process using db_session and the rest of the site use the 4kb cookie session.
Is this possible. It seems like it could be a really bad idea, but I don't really want to rework the dynamic registration process or really use db_session for whole site as it will eventually make the site run very slow if too many users are online at once.
so I'm think I can just set the variable in config to be true only when the registration controller is loaded(by checking the url via $_SERVER or the uri helper if I can load it in the config which I'm guessing I cant).
Does this seem plausible?
It seems like it could be a really bad idea
You answered your own question :) You'll have issues when the user switches from one page to another. What happens if they open multiple windows, press a 'back' button etc. You'll need to switch the cookie over when they start registration, and switch it back at the end. It will be very very messy for basically no gain.
but I don't really want to rework the dynamic registration process or
really use db_session for whole site as it will eventually make the
site run very slow if too many users are online at once.
The reality is; your website has to be huge to have ANY real performance issues by using a DB for your sessions. Any if you are not using the DB, then you are relying on the cookie stored on the users computer. Depending on your site, this means they might have the ability to edit that cookie and change "admin = true" or something.
Just use the DB session - I think you are overcomplicating the situation.
I'm still pretty new to AJAX and javascript, but I'm getting there slowly.
I have a web-based application that relies heavily on mySQL and there are individual user accounts that are accessed and the UI is populated with user specific data.
I'm working on getting rid of a tabbed navigation bar that currently loads new pages because all that changes from page to page is information within one box.
The thing is that box needs to reload info from the database, etc.
I have had great help from users here showing that I need to call the database within the php page that ajax is calling.
OK-so pardon the lengthy intro-what I'm wondering is are there any specific limitations to what ajax can call that I need to know about? IE: someone mentioned that it's best not to call script files and that I should remove scripts from the php page that is being called and keep those in the 'parent' page. Any other things like this I need to keep in mind?
To clarify: I'm not looking to discuss the merits/drawbacks of the technology. I'm wondering about specific coding implementation that I need to be aware of (for example-I didn't until yesterday realize that if even if I had established a mySQL connection on the page, that I would need to re establish that connection in my called page as well...makes perfect sense now).
XMLHttpRequest which powers ajax has a number of limitations. I recommend brushing up on the same origin policy. This is a pivotal rule because it limits where AJAX calls can be made.
First, you can't have Javascript embedded in the HTTP response to an AJAX call. That's a security issue.
No mention of the dynamics of the database, but if the data to be displayed in tabs doesn't have to be real-time, why not cache it server-side?
I find that like any other protocol, Ajax works best in tightly controlled conditions. It wouldn't make much sense for updating nearly the whole page, unless you find that the user experience is improved with an on-page 'loader'. Without going into workarounds, disadvantages will include losing the browser back button / history, issues such as the one your friend mentioned, and also embedded resources and other rich content can suffer as well, and just having an extra layer of complexity to deal with in your app. Don't treat it as magic sauce for your app - make sure every use delivers specific results that benefit your client / audience.
IMHO, it's best to put your client side javascript in a separate page and then import it - neater container. one thing I've faced before is how to call xml back which contains code to run such as more javascript - it's worth checking if this is likely earlier on and avoiding, than having to look at evals.
Mildly interesting.