Jump to content

Community

Marcher Technologies

+Clients
  • Posts

    17,657
  • Joined

  • Days Won

    98

 Content Type 

Profiles

Downloads

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Store

Everything posted by Marcher Technologies

  1. You are correct, it is not my decision. I fail to see how any opinion is irrelevant under any circumstances, however. This topic is mostly opinions. The only reason I am even posting here is because the single worst thing one can do for the security of their site is depend on obscurity, and cloudflare recommending they do, and this request being made of the script as a result, is an indication someone must actually believe such a thing is a good idea. Such is a notion that should be dispelled in a hurry, and without mercy.
  2. Also, consider that there must always be a backup for javascript disabled. what then? The user just can't post at all because their external image or embed cannot be processed on the server side because it's all client side? They can post due to backup server-side code and they get the IP anyway? It would be rather pointless to make the effort if merely disabling javascript in your browser sidesteps the protection. Conversely, not allowing them to post because for some reason javascript is not available is not acceptable either. It's a no-win scenario unfortunately. Cloudflare's demand on this point is Indeed unreasonable - the only place to offload such a request to the client is not a guaranteed thing. Javascript is optional, able to be disabled. PHP is the only backup system to process that data available.
  3. Not shutting it down because I think it would be too hard - if there is a will, there is always a way. Read the rest of my post, and consider your own scripts. That is indeed an unreasonable demand cloudflare is flying - a script that merely makes a outbound connection, then saves some data to the database, then redirects would be a convoluted process making the request in JS. They are outright banning the use of PHP functionality widely used.
  4. Ryan.. You should know as well as I do that's not actually feasible. Possible? Yes, with an unholy amount of work. Worthwhile? No. The gain is far too small for the massive amount of effort one would need to exert, especially when it's something that should be handled at the server level, not the application level. I would submit that cloudflare's requests are unreasonable. It is basically saying we can't make any outbound connections at user behest for any reason in php, and *must* ferry everything to JS. That is purely unreasonable. For a standard php script, you would then need to push it to display for the js, then have an ajax controller to handle the things you need to happen *after* the connection has been resolved. It would produce highly convoluted code to actually make this a practice.
  5. Ok, I'll humor you, just to point out how utterly unusable the result would be. A large portion of the current web's functionality involves making an outbound connection at a user's behest. It is not feasible to simply remove that functionality, users are heavily dependent on it. OEmbed is used for media embeds, outbound connection at user behest. You are basically telling your users they cannot embed any video. Login through facebook, google and such services, is again, making an outbound connection at user behest. No logging in through social networks either.
  6. ..... You tout that blog entry, Yet you didn't even read it fully. :/ Again, for the.... 10th(?) time, security through obscurity here is meaningless. Make having the IP worthless, there will always be a way to get your server's IP.
  7. Had forgotten about that, thanks. Here's hoping htmlpurifier does end up officially supporting it. 7 is a vast improvement in the language for many reasons, including this one...
  8. fatal errors throw catchable ErrorException's in recent php versions, which is why I didn't quite understand how the error was slipping past. I'm not sure why that hacky approach is needed when mere adoption resolves the issue?
  9. The only way I could see that happening by the code is if the line with the error was silenced with @, in which case there's nothing that can be done, and don't do that?
  10. ...... They already are caught? \IPS\IPS::errorHandler and \IPS\IPS::exceptionHandler....
  11. Hello, Unfortunately, this modification does not support truncating(or even altering really) the content provided by the rss feed. There is no good way to do so in frank honesty, you either strip html and thus lose formatting or end up producing broken html.
  12. Hello, The very warning portrayed(and summarily ignored) in your first screenshot should provide a hint. However, for clarity, making backups(and the other options listed there) is not something that should be handled at the web script level, as large databases/tables will time out attempting such operations through a web interface.
  13. Actually not arguing that, just providing information, as that stopwords list changed may not be enough due to that MyISAM limitation.
  14. It is a default list of words that are so common as to be arguably 'useless' in a search term, as the majority of rows in the database would be likely to be a result. I would encourage you to note that even making this list much smaller, many of the words may still return no result if using MyISAM due to the limitation listed here: http://dev.mysql.com/doc/refman/5.7/en/fulltext-natural-language.html
  15. Set(specifically modified to support use in a template, remove the {{}} if working in a PHP file): {{\IPS\Output::i()->jsVars['my_data_key'] = $data;}} Read in JS: var myData = ips.getSetting('my_data_key'); Using the data attributes properly tends to be a bit more complex, as you end up diving into making controllers and/or models in the js framework.
  16. Custom Profile Fields Morrigan, not Pages Database Fields. Pages Database Fields have you provide a key, or identifier, with each item, thus this issue doesn't exist there.
  17. You are correct up til there. He's referring to the fact if a user has provided a selection of value 1 and value 2 while it was configured originally, after updating the field options, it will appear that the user has selected value 1 and value 3 instead in displaying the saved field data. It actually changes the 'value' based on the position in the list.
  18. Near as I can tell, it's consistently happening for me on this site. I have it configured to send me an email for new messages, so while I read every one, I rarely have the time to reply to the deluge in whole I see nearly every week(I have to pick and choose...), much less re-read it on site. It seems to occur whenever i receive a new pm, and have read it on site. Immediately after I do, the next most recent message unread on-site will pop up, no matter how old that may be.
  19. Is guest caching enabled? If so, the only option *is* what Rhett suggested. Checking that for cached pages in the script would require a query, something the guest cache at this time completely avoids the need for, intentionally, as that is the point of the guest caching = no database connection needed to generate the page.
  20. Thanks ever so much for this. Extremely helpful. I just wanted to note there seems to be a rather odd (execution order?) issue in regards to using the constants in the \IPS\core\ProfileFields namespace if it so happens to be the first time the class is being called. {{$fieldData = \IPS\Member::loggedIn()->profileFields( 2 );}} works fine, but {{$fieldData = \IPS\Member::loggedIn()->profileFields( \IPS\core\ProfileFields\STAFF );}} results in "Undefined constant 'IPS\core\ProfileFields\STAFF'" in that situation. The only solution I can think of would be to move said constants into the \IPS\core\ProfileFields\Field class itself, but that's a fairly large change - in the meantime using the value of the constant desired instead of the constant itself as in example one works fine. To be very clear, not complaining at all, I'd rather have to do that than issue a direct query for the data(a try/catch block in a template is verrry messy, I've found, so saving that alone is extremely helpful), and I didn't see that one coming in making the request either - it's very subtle.
  21. I actually had something similar happen working on something for a client, try turning *off* prefetching in your browser. Specifically, if you are using FireFox, it makes a literal ton of connections during normal browsing by default: https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections I mention this as I haven't seen another browser be this aggressive in prefetching by default, and it is so aggressive it will trigger a block from any sane CSF config.
  22. This is now fixed. Seems I missed something in adding support for the core menu manager.
  23. It seems that even though none of the actual code-level changes affect this app, something new was added in the packaging for release. I'll put an update up later today with it repackaged in 4.1.7. In the meantime, if you extract the .tar and upload the files normally, it should still install that way.
  24. Why in the world would you utilize a less secure password hashing algorithm when the only requirement to use blowfish is already met by using the minimum required version of PHP for the suite?
  25. {{if \IPS\Dispatcher\Front::i()->application->directory == 'nexus'}} {advertisement="ad_global_header"} {{endif}}
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy