I think the HTML Viewer widget can be very useful for integration of sambapos with outside functionality (scripting, custom reporting, etc), but I’m not very clear on some of it’s properties and functions.
Is it possible to put the location of a local file as the URL? I tried this:
file:///D:/report.pdf
which works in my browser, but in Sambapos HTML viewer it says:
The page cannot be displayed
The page you are looking for is currently unavailable. The Web site might be experiencing technical difficulties, or you may need to adjust your browser settings.
Can the HTML Viewer show local files (or at least local HTML pages) as well? If so, what should be the format for the URL property of HTML Viewer?
I solved this for now by installing a simple http server locally on my computer, but I’m hoping there’s a way to do it without this workaround.
After changing the local file (report.pdf) to give me different content, I need to refresh the HTML viewer content.
I know there’s a setting “auto refresh” and “auto refresh interval”, but these don’t seem to work very well. When I use the auto refresh, it refreshes to a blank page (as if it’s “forgotten” the url that I just gave it).
When I update the local file to a new version, the automation command I’m using (and rule/action) will set the url property of the html viewer to report.pdf (same name as before), so it will not refresh the contents.
Am I doing something wrong with these settings? Is there another way to refresh the HTML viewer through rules and actions?
That would be extremely insecure. I would strongly advise not to implement any way for it to link to local files directly. If your comfortable with security and setting up your own web server you might be able to serve some of the function your trying to do.
Could you elaborate on the reason why it would be insecure to link to local files?
It seems to me that it would be way more insecure to have to setup a http server for this purpose and have to deal with securing that?
It is a simple HTML viewer which is not secure to begin with. Your basically giving easy access straight to your computers files by allowing it to do that through a simple html viewer. Its like leaving the door unlocked but putting a sign in front of it that says do not go in. What your asking for can be done through a web server or it would need to be programmed to work without a simple html viewer.
Now if the samba install was on your personal computer and nobody else was going to use it… then sure it would be the same as looking at the files on your personal web browser… but thats not how you would deploy a pos package.
You do not have to link a webserver to the internet. You can keep it working only within your network. That would eliminate the security risk your worried about. If your not sure how to do that then I would question if you should try implementing it in a live setting or not until you can understand it further.
It has been discussed that custom reports will be able to be made in future version of SambaPOS and you will be able to customize the output of it in the Reports section of the Samba main menu. This would allow you to view your reports alot more securely.
I agree however that the widget is great for integrating outside services. It just needs to be handled securely on the backend. I am currently trying to use it to give integrated access to a TimeClock for my employees. THe time clock will be ran from a local webserver.
Some people use cloud based services for their business and this would be an easy tool to deliver a front end as it if was part of Samba through a screen button.
I’m sorry but I still don’t understand the security problems you are talking about.
The people who are using the computer (restaurant staff) are only able to access sambapos, not anything else on the computer. And within sambapos, the HTML viewer would be directed (through automation commands, rules and actions) to a local file (a report for example) which has just been generated on the spot by these same commands/rules/actions. They would not have any way to specify that they want another file than just that file, since the “is toolbar visible” property of HTML viewer is not ticked.
So what exactly could they do which they weren’t already able to do because of the HTML viewer showing one specific local file?
I know custom reports will be possible in future versions, but I need my setup working as soon as possible, so for now, I’m trying to get it to work with what’s available at this time. I also want to do other things with this apart from custom reports.
Using a server to accomplish this is not really a problem for me, but it just seems to be overkill in this case.
For PDF viewing (and also FLEX viewing) don’t expect a full featured web browser widget. There are embedded Chrome or Firefox implementations that offers more features but unfortunately including such stuff makes our download size hundreds of MB’s. As @Jesse stated IE’s embedded browser behaves differently for security reasons and instead of displaying PDF inside widget box it will probably execute Adobe PDF Viewer as an external application. For this reason I’ve intentionally disabled file:/// protocol.
I would not want that module to allow that it is not secure to do that through an html viewer. Its not as simple as you make it sound. It would expose the system unnecessarily to possible compromise.
Ok, that explains the local file access problem then… I have to say I still don’t get the security problem in my specific case, but I won’t ask you to try and explain this any further. I guess I don’t have enough expertise on this subject to understand.
@pipo this is not something we enforce to keep you secure. This is how embedded IE works. Instead of displaying files internally it executes default pdf viewer application for local files. Not to confuse users I’ve decided to disable it since Start Process action does the same thing.
This tutorial might give an idea about browser refresh but you’ll need to setup a tiny local web server to be able to do that. This solution may solve your PDF viewing issue too.
The Start Process action can do the the same thing as HTML viewer, but only outside of Sambapos. In other words, when we open a file with the Start Process action, it will popup another window. If we want to limit our users to only use Sambapos (with software to restrict access to everything else), this will cause problems. For example if they touch elsewhere on the screen the popup will disappear in the background and will not be accessible anymore. That’s why I really like the idea of using HTML viewer for extra functionality, as it keeps everything in one interface.
I guess the combination of a web server and this live.js script should do the trick. I’ll try it out immediately. Thanks a lot…
I needed a small workaround, but it’s working perfectly now.
Since the live.js script only works in a HTML document, I had to embed the PDF file into the HTML document with an object tag. The live.js only checks if the HTML document it’s embedded in has been updated, not whether any embedded objects have been updated.
So I had to make the script that updates the PDF report also update the datetime of the HTML document the PDF is embedded in.
