Is there a way to disable direct upload of images and attachments from the ActionText/Trix Editor and replace it with a POST request to the rails backend to do the upload to S3?
I'm trying to do this to audit any user upload actions from Rails application standpoint.
Updates: I'm thinking I can probably extend the ActiveStorage::DirectUploadsController to do this audit. I'm still curious about the original question.
I'm also thinking about writing javascript to change data attribute (data-direct-upload-url) of <trix-editor> html form element.
Related
I'm new to Firebase. I just want to build a simple HTML form on Firebase that sends email to me as well as to the user who fills up the form upon submit button click. I do not need any user authentication or database. After that I want this HTML form to be able to embed on my Blogger website, probably using iFrame. So how can I go about doing this?
Based on my understanding, for a HTML form to send email requires server-side coding like ASP.NET and PHP, may I know which language should I use on Firebase? Does Firebase provide such SDK that I can simply write in JavaScript and create a .js file for my form handler?
I already know how to deploy HTML files to my Firebase project using Node.js and get the URL of every file that I deployed, e.g. images, css files etc. Any help would be greatly appreciated, thank you.
With Third Parties (by now)...
After many hours researching about this, the solution seems not to be inside Google at the moment, but using a third party: SendGrid.
Tyson Bailey created a small example and explains this methodology in this blog post.
I'm starting a large scale app and need advise on setting up the folder structure and all. So I'm not sure if on Meteor startup if it loads all of the components to one file or not ( if all the components are in the client/ folder )
If it does not load all the components and send it to the client initially the this question has been answered. if Meteor do send all the components to the browser then need a way to fix it.
At the moment I have like 70 components and do not wanna send all of this to the user on the initial page load.
It seems as though incremental/on-demand loading for components is in the 'todo'/'future feature' stage.
From - Trello: Meteor Roadmap
Right now, on initial pageload, you download all of the JavaScript,
templates, and css in the app.
This task is to make it so that you download just the parts that you
need. You might download additional parts in the background, or
on-demand as you navigate through the app. (To be clear, this would
apply to the JavaScript, CSS, and templates, not to database contents,
which would continue to be handled by the subscription system.)
It should be possible to secure some of the additional parts so that
only certain users can download them. For example, only admin users
could download the JavaScript and templates for the admin console.
Related: when the app is updated, only download the changed parts, not
the whole app.
I made an ASP.NET MVC application which allows user to create dynamic websites. I need to add feature which will allow to download from server off-line version of choosen website as static html files with menu, hyperlinks, images, documents etc. It should work similar to applications such as Teleport Pro, but I have to choose from Admin Panel which content should be export.
Client wants to burn static website on CD, save on pendrive.
Do you have any ideas how to begin? Please help.
I currently have implemented that in a current project...
User is able to change anything in the frontend and at the end he can publish and download the offline files... the site subscribe users and show all prizes, winners and more information about that campaign.
All was done in ASP.NET MVC3 under .NET4 and hosted in AppHarbor.
It's composed at several applications but for what you want, you develop the Backend and the Frontend, and to generate the static files, simple use the Frontend to grab the full HTML
As an example, I can show what 2 users did...
Callme.dk did http://callme.julekal.info and
Sony Nordic did http://sony.julekal.info
plus, you can simply point custom domains to it as well like http://sonynordicxmas.net/
To publish and generate all files:
one part of the editing:
So I give the users, offline access (through the .zip file), online access (through the frontend application) and the ability of using custom domains...
I think the only way this might be possible is if you go to every single page and then use your browser to "Save" the web page script and all.
However this causes several issues;
You never quite get everything and you need to massage the HTML produced, dowload all the images etc to get the page to look right
Each html file now has an associated folder with the same name and each time you do this you will get another html file with a folder. You can combine all the folders into a single one but that leads me to item 3.
You will need to edit each html file to clear up any pathing issues if you want to share a single source folder.
Data is no longer dynamic!
You need to, if you want to link all the pages to each other, edit every single html file and resolver the anchor tags.
This is too much work and I think it actually breaks the true requirement.
Don't do it! :)
Hii,
Any one knows how to upload files to the physical location of the server. It is possible using file upload control that i know. But i want to avoid the external postbacking of the page. For e.g exactly like what in the yahoo mail did.
In yahoo mail latest version if you attach a file that won't post back and attach that file in to server. What is the technology behind that?
Normally when you submit a form it does a POST request to the server, causing a refresh. Ajax requests get round this by using JavaScript to send the POST data through to the server, and that doesn't need a page refresh.
Ajax requests can't be used to send file data though, so the best way to currently do it is with an iframe hack - you use JavaScript to dynamically build up a form within an iframe, submit that form via JavaScript, and listen for the iframe's onload event. So you know when the form has been submitted. A version of this approach is detailed here:
http://www.webtoolkit.info/ajax-file-upload.html
Other methods to do this would include using a Flash-based solution like http://www.swfupload.org/ or a wrapper like http://www.plupload.com/ - these will prevent you having to roll your own solution and will also provide some extra functionality - upload progress feedback, for example.
Is there a way to programmatically set the name of a file to be uploaded from a web page? I suspect that browser security restrictions make this impossible, but I'm hoping someone will prove me wrong.
I have a web application that needs to let the administrator upload HTML. The admin selects the HTML file, then the app uploads that file, plus figures out all the supporting files (images, stylesheet, etc) and uploads them too. There doesn't seem to be a way to programmatically upload the supporting files from a web page, since the user has to specify each file explicitly.
Currently I have a separate Windows app to do this, but it would be ideal to have this functionality integrated with the rest of the app. My back end is ASP.NET with C#.
There is no way to programatically grab files from a user's computer via the browser. This would be a security violation if a website could just grab things.
Yes you can (in modern browsers)...
You can get and set the value of HTMLInputElement.files.
See this answer.
No, you cannot do this without a client-side application or special plug-in.
Browser security doesn't allow the server to obtain information about the hard drive contents of the client.
You may be able to do this using some form of browser plug-in. This is more work for you (and there are potential security implications for this beyond those found when you just have users run your app). However, it may prevent a more integrated experience for your users. I'd hesitate to eliminate the application completely, though. Browser compatibility issues are common.