I use the latest CI version. In config.php:
$config['global_xss_filtering'] = TRUE;
I can't change this.
I need to save adserver tags (will stored in files, not DB), which contains also Javascript. So with this setting I cant save the adservertags, CI or the input filter removes some parts of it.
My first idea was to encode the adservertag with base64 in the client and then on ther server decode it again, what dou you think?
Sounds like a plan.
Except there is no native way to base64 encode on the client. However, a friendly fellow on Stack-O has solved this for you already: https://stackoverflow.com/a/246813/183254 Be sure to share an upvote for them.
Related
I created Candy Machine and I noticed that some NFT images are not displayed neither on wallet or solscan. Metadata and images were uploaded and pinned on Pinata using Candy Machine upload command which finished successfully.
Here is an example of broken NFT.The metadata URI is pointed to: and image is pointing to. I looked at metadata several times and could not find what is the issue and why is this happening to some of the NFTs (here is the example of valid NFT that does not have this problem).
Questions:
What is the problem with metadata which is causing image not to be displayed?
What is the best way to fix this? Metadata are mutable and I am planing to use metaboss to update URI of metadata file. Is this correct way of fixing this problem?
If you look at the URI metadata on solscan here
https://solscan.io/token/4ToXb3aD5YLpXqyZhcdp5ynpbXXFFjKjsaw1x94CTd7A#metadata
and swap to the URI version of the metadata for some reason it's returning an object keypair value out of every single character in the JSON for some reason, extremely weird. I'd highly recommended reuploading this JSON metadata file and then updating the metadata URI in the NFT to make the changes.
Metaboss is a great tool as you have researched that can do this for you.
Upload new Metadata json to ipfs or arweave.
Use Metaboss to udpate the NFT's metadata URI.
Hopefully this fixes your issue.
While not a conclusive answer as to "why" this happened, I don't really know the why. This is my first time in all the NFT's that I've seen that have behaved this way upon an upload and displaying the metadata.
If that doesn't fix your issue please stop by the Metaplex Discord server and chat with us there. :)
Edit: After further inspection it turns out your JSON file is of an invalid structure for this particular NFT so will definately need replacing.
Tony Boyle has a great point with updating your json.
Your problem gets visible when you run the json through a JSON validator.
It will show that you have too many } in there. Therefore parsing the JSON fails in solscan, phantom etc.
What you have to do is
Modify the metadata to be a valid JSON file
upload it again
update the NFT uri e.g. with metaboss (if you need to update multiple NFTs) or if its just one / a few https://sol-tools.tonyboyle.io/update-nft
So I have a site where I upload large video files using html 5 to azure storage using an sas signature. It seems to work fine on most systems and browsers but doesn't seem to work on iPhones. I finally routed the call through fiddler via proxy and got the response from the storage server.
Here is the CORs rule I have set up.
What am I missing here?
Good evening,
There are a few things I would like you to try simultaneously, when you get a chance:
1. Change your Allowed Headers to: "Origin,X-Requested-With,Content-Type,Accept,Authorization,Accept-Language,Content-Language,Last-Event-ID,X-HTTP-Method-Override, x-ms-*". NOTE: You may not need all of these, but for now, add them all to see if we can get it working.
2. Change your Allowed Methods to: NONE, PUT, OPTIONS
3. Set the Max Age (seconds) field to 0
4. Create another rule, and do not have a comma-separated list of allowed origins. Make a separate rule for each origin. (I've heard of certain browsers not liking the CSV).
Once all is said and done, if the above does not work, try removing "Authorization" from the allowed headers since it looks like you are not using that (but first, try it with it).
Please let me know if you make any progress with the above ideas.
I have a concrete5 site, which uses 'designer content' an add on available via their market place.
Our clients site requires the use of macrons for their language.
Now this is fine throughout 99% of the site, whether hard-coded html or via a content block etc. However, when macrons are used inside a block created with 'designer content' the macron is replaced with a "?"...
Can anyone help?
Unfortunately this site wont let me post an image to help you see whats going on due to my 'low reputation'....riiiiight thats helpful.
Thanks in advance!
usually the apparition of question marks "?" instead of certain characters is the sign of a charset coding problem. With C5 you should be using a generic UTF8 encoding however if your database table was set to use a different charset or if your php settings are set to a different charset, then you will get those weird characters.
You should start with your php.ini and set the charset to utf8
If that doesn't fix the problem, check this thread, it has a useful script to use to fix the database
http://www.concrete5.org/community/forums/usage/utf-8-or-unicode-problems-preventing-corrrupt-fonts-on-the-front/#52300
Be aware however that if content was saved while the charset was not correct, you may discover that the content still looks weird and you will have to insert it again AFTER having set the correct charset.
I am trying to create a social network application using elgg.Since i am pretty new to elgg i like know whether i can define url routing like in cakePHP
I need the url like this
mydomain.com/username instead of mydomin.com/pg/profile/username
Is there any way that i can avoid /pg/ and /mod/ from the urls??
I am using elgg version 1.7.8.
I am not interested in url rewriting with .htaccess.
Thanks in advance
elgg itself is using .htaccess file to redirect /pg, /action etc. So, I think there is no other way than using .htaccess.
Elgg's page handling is pretty bad but you can register handlers as follows.
for /mypage:
elgg_register_page_handler('mypage', function($pages){
//content here
//the $pages parameter is an array. so /mypage/a/b with return
// array('a','b');
});
Matt Beckett has written a profile URL plugin (https://community.elgg.org/plugins/1091233) that, though for 1.8 and above, is only 35 lines of code and does exactly what you ask. You should be able to adapt this quite easily for 1.7.8.
He has also written a fuller page handler hijack plugin that may help if you have other use cases apart from user profiles - see https://community.elgg.org/plugins/854839
It is also only for 1.8 and above, however, and may take more effort to backport than the first.
What is the best practice when serving files from the Zend Framework MVC? These files have to be served from the MVC as they are protected.
I know you can read in the file and place it into the Response object but this seems like a bad practice as you would be reading the entire file into memory then serving it. Right now I usually do:
header('Content-type: image/jpeg');
fpassthru(fopen($path, 'rb'));
exit;
But this also doesn't seem right as I'm stopping the execution of the script. Any suggestions?
I see nothing wrong with just exit(); What you will need to be careful of is any output buffering layers you may have on (gzip compression, etc). Large files could blow up those buffers pretty quick, so you'll want to close them out and potentially 'chunk' your output with a fopen/fread loop.
I would suggest building a super-simple script for retrieving files based on ticket system like in CMS you generate ticket to DB - filename, unique-hash and than redirect to the super-simple file-retieving script (file.php?hash=asd52ad3as1g5). It will get the hash from query and based on it fetch the real filename and push that to output as you have written using fpassthru. The hash need to be unique and hard to guess...
You could try using the X-Sendfile header. It is supported by lighttpd and newer versions of apache. Basically the webserver will replace the output of the script with the file you specified. The downside being that it is specific to the configuration of the webserver, so you may be on a host that doesn't support it.