I got a question regarding a upload, edit and serve setup.
I have a setup where my shopify website lets users upload images to a google cloud bucket with javascript. When the file is uploaded to the bucket it's send to a compute engine which edits the files and the file is then uploaded to another bucket. All this is done.
But now I want to serve the file to the user on my shopify website. I can't figure out a way to do this. Is it even possible with my current setup? My problem is how to identify the user-session which uploaded the file, so that I can serve the file back to that person.
I hope someone has knowledge about this and is willing to help. Thanks!
Every person that logs into a Shopify store gets a customer ID. You can use this for your uploads. Ensure images get manipulated with that ID in mind. Now, use an App Proxy that sends the same customer ID to your App. Your App can then use this ID to find the image previously uploaded, and you can return it to the shop. A very common pattern of Shopify use.
As for getting the customer ID, one way is to dump it using Liquid since you have {{ customer.id }} or you can sniff it out of the cookies Shopify stores for a user session. It exists, but you'll have to dig for it, I forget its exact code.
Related
I am creating an app for google assistant which will collect data while a user plays a game and then send that data to a project database. The API I am using to sent the data (synapse) requires it to be in file format, however, I can't find a way to create a file for the data due to the nature of google assistant apps. Am I overlooking a way to do this/is there a way to get around this and send the data somewhere else to make it into file format? The data is stored in a JSON object.
The conversation that your users have with your Action will be relayed from their Assistant device (such as Google Home) to Google's servers, which do a little processing, and then to your server. Your server is then responsible for sending back a reply to Google's servers, which sends it on to the Assistant device. This is very similar to how a web browser and server work, and for good reason - your server accepts commands via a "webhook", which is just a fancy way of saying that Google's servers contact your server via HTTPS, and you're sending back a reply via HTTPS.
Your webhook can do anything - as long as it does it fast enough. You can store what command the person has issued and either aggregate a number of them into a file format to send, or send each one.
Your Action does not, itself, run on the user's device any more than a web page with a form "runs" on the user's device. It displays there, just like your Action is read out loud... but almost all interaction is sent back to you with minimal processing on the device itself.
I'm developing my first iPhone app to make what is effectively an app version of a fantasy league I created for work colleagues.
I am using Parse for the backend of the app. I only want people to be able to register with their work email address ie only if their e-mail address is _#mycompany.com
I'm sure this would be quite easy to someone who knew what htey were doing but I'm kind of new to this so any advice would be much appreciated.
Thanks
You could do this in a number of ways. The easiest way would be to have the validation happen on-device - just check the e-mail address the user has put into the app, and only allow the registration to happen if it matches the domain you want to limit it to.
However, although this is very easy it's also open to abuse and it's not very flexible (if you want to add additional domains, you have to update the app).
Fortunately, Parse offers cloud code, which lets you validate data server-side. Cloud code is written in JavaScript, and you then upload it to Parse. There is full documentation on Parse's website, including examples for validating data.
I have built a Custom B2B app for one of our clients. My question is how to automate the distribution of the redemption codes.
I have already looked at some of the MDM providers. Their solutions are too expensive and all we really need is a way to distribute the app from a webserver, not manage a bunch of mobile devices.
As you probably already know, when a client buys a Custom B2B app through the Apple VPP program, they get a spreadsheet with valid redemption codes for the number of licenses they have built. This spreadsheet has 2 columns: 1) redemption code 2) URL to redeem the code
I want to provide my client with a URL where they can send their users to download the app. They just don't have the expertise/infrastructure to distribute the app themselves. And emailing clients is not going to work.
I'm not a web guy, but it seems to me that we could write a webpage that would look at the spreadsheet for the next available activation code and then redirect the user to the associated URL. I'm not concerned with the number of licenses they distribute since I have another way of auditing the real number of users (Flurry). So I want this to be as painless as possible.
In fact, I have multiple clients and want to provide them each with their own URL for their clients. It seems like this shouldn't be too difficult to code.
The problem is, I'm not the guy to write that code. Any ideas on how best to do this?
Assuming that you don't want to show the user a website you should be able to do this with an online service like parse.com and the features it offers.
From a user POV you would supply them with a link which directed them to parse.com with a path and parameters indicating the action to be taken (get app) and what account is associated. This would redirect the users browser to the appropriate destination.
The main issue (and this applies to any solution) is knowing if the user actually followed through and used the code. i.e. should it be removed from the DB so it isn't offered to another user in future. Then you would update the DB each time you get a new spreadsheet.
Anyway, this could be achieved with a little javascript in parse.com, specifically, by using cloud code which can interrogate and modify the DB and then redirect the user.
Obviously if you need user authentication of some kind or other restrictions then you would need to start adding some web interface on top of this in order to collect the details.
I am building an iPhone app in which users (or employees) will be able to go to restaurants and update/give an estimate of the waiting time at that location. To do something like this, would it be most efficient to use an XML webpage and parse the data that is currently there and update that value with the user's input then reload the XML database? Obviously any user should be able to update the site so it needs to be done from a web-server.
Also, if anyone knows of a similar example for this, that would be spectacular!
Thanks for your help,
you can take a textfield in which you can fill the value and then send it onto the web server through XML or JSON web service and the other users can see the update from the web service.
I have a web site with various graphs embedded in it that are generated externally. Occasionally those graphs will fail to generate and I would like to catch that when it happens. These graphs are embedded in multiple pages and I would rather not check each page manually. Is there any kind of tool or perhaps a browser addon that could periodically take screenshots of different URLs and email them in a single email? It would be sufficient to have scaled-down screenshots of full pages emailed maybe once a day to me, allowing me to take a quick glance and see that all the graphs are there and look okay.
I'm a big fan of automation. Rather than have emails generated that you then have to look at, take a look at 'replacing custom missing images in jquery'. This will run a piece of Javascript for each image that fails. Extending that to make a request to a URL that you control, which may also include the broken URL (or just the filename that is broken) would not be too hard. That URL would then generate an email, and store the broken URL so that it doesn't send 5000 emails if there's a flurry of hits to your page.
Another idea building on the above is to effectively change the external 404 from the source site to a local one (eg /backend/missing-images/) - the full-path need not exist - you are just generating a local 404 record in your apache logs. Logwatch will send a list of 404 pages from the apache log to you daily (or more often, if you want) by email.