Trying to find a solution to this, we have our LMS Server, and content servers all across the US, so the user gets their content from the closest location.
I've come across a solution using SCO-Fetcher, mentioned in these two links below and illustrated below, but I cannot find any information on how to implement a similar solution.
here: http://elearningrandomwalk.blogspot.com/2006/08/sco-fetcher.html
and here: http://www.adlnet.gov/Technologies/scorm/SCORMSDocuments/SCORM%20Resources/ADL_CrossDomainScripting_1_0.pdf
If anyone has any thoughts or information regarding this, it would be most appreciated.
I work for a content provider who has had to interface with a lot of different LMSs and cross-domain has always been a painful issue.
The document you linked to not-withstanding, SCORM doesn't really cater for cross-domain at all. My experiences with cross-domain has been against the AICC standard. In the past we've used a signed java applet to perform the cross-domain communications, but currently we are using a little hidden flash* SWF file which we talk to via javascript. This requires the LMS to have a crossdomain.xml file installed on their web server to allow the communication, which some of our customers balk at.
* Our product heavily uses flash already, so this was not an onerous requirement for us.
The solution that we are seriously considering now is a variation on the "Run-time service on Content Server" as suggested in section 4.8 of the cross-domain scripting document.
The content server would run the courseware itself, as if it were an LMS, and proxy all the API calls to the real LMS. The diagram below shows the communication paths:
Also, your launch URL wouldn't be directly to the content (e.g., http://abc.com/content/sco.html) but to the software application on the content server (e.g., http://abc.com/access.php?content=sco.html&permissions=OAUTH_ID), which would then serve the content as if it was an LMS itself.
Also, just came across this article on cross-domain communication which, while not SCORM specific, might provide some alternative ideas for implementation.
I know this is an old question, but thought I'd share: I had a similar situation a few years ago and settled on an iframe hack to get around the cross-domain restrictions. All it requires is a bit of JavaScript and HTML. It works on older browsers, including IE6.
Chuck, what solution did you wind up using?
Related
Let's say you set up a custom protocol handler to run an application with some startup data, right?
myapp:\\somedata
How secure is that data? I'm having trouble finding any resources talking about:
Do browsers cache this data?
Can other applications see this information get passed and how?
I've found resources talking about obvious problems, like attacking sites can abuse your protocol if they find you have one.
Otherwise, for developers looking to use their website to launch an app in this way, what do we need to be concerned about if we don't want anyone else seeing "somedata"? More specifically, how is the data accessible to attackers?
Any MDN or other official references would be much appreciated!
This is maybe quite a broad question and I tried to look for other stack exchanges where addressing my question would suit better – but in the end I decided that it might be still a question of a technical nature, and so I am posting it here:
I recently started to think more about privacy and security and I realized that I as a web user can only do so much about staying untracked. VPN, (slow) Tor, privacy helpers, add-blockers, Firefox are just a few tools to name, but still I realize that the information that I normally share (like installed add-ons, browser size, IP location etc.) can still very well be fingerprinted.
Normally as a web-developer I am told that we should add analytics, that we should find out more about the users to «make a better service», but I think I would like to do the opposite.
So:
Are there steps I could take, when building a website, that help the visitors to stay untracked? And I don't mean «not installing google analytics», I mean things like somehow actively messing with the statistics, so that my hosters server is incapable of tracking things correctly or similar things...
Right now I can't really think of anything, but I somehow believe that I as a person who builds bricks of the internet could and should be able to influence these kind of things directly...
For now I see the obvious things:
- not using statistic services
- use https
- not using any third party tools that might include tracking or open doors for other trackers
But still this seems to just omit the bad things, but I can't actually do active stuff...
So I would be very glad to hear your thoughts about this. (Or guide me to a place, where this discussion fits a better..)
Cheers
merc
As a web developer, you can only control your website.
Assuming you aren't caching any data or using cookies, then users shouldn't be tracked while using your website by tools like 3rd party cookies.
Here is a good article about online tracking and how it works.
As far as I know, there isn't an effective way to actively mess with tracking statistics. Your best bet is to avoid installing libraries or tools that track your users.
This post is intended to start a deeper discussion on Single Page Applications for the web. There are questions that do not seem to have a clear answer in most resources on the subject.
They are in my mind
Authorization and authentication.
With entire web app being on the client, it may make calls to the server in any of its functions, even those that the user does not have rights to. The fact that the user cannot see a menu, does not preclude that person from invoking java script functions. This is easily handled in MVC app, for example, by using controllers that validate user rights to a specific function based on a cookie for example. However, some SPA apps just use single controller with Breeze or Web Api, which make authorization server side impossible.
Memory management on the client
For small sample apps this is not an issue, but imagine an app with 100's of screens or an app with a single screen that pulls thousands of records over the course of one day. With persistent caching one could imagine large memory issues, especially on under-powered devices with little RAM, like phones or tablets. How can a group of developers had SPA route without a clear vision of handling memory management?
Three Tier deployment
Some IT departments will never allow applications with a connection string to a database located on front end web servers. Every SPA demo I have seen is structured exactly like that, including Breeze or Web Api for that matter.
Unobtrusive validation.
It would require developers to use MVC partial views and controllers instead of just HTML files, which seems to fly in the face of SPA concepts, while it provides a very robust way to easily incorporate validation and UI to support it into web applications.
Exposing primary integer based keys in the url.
This is non-no in OWASP.
As a result, SPA applications "seem" to target areas with few security requirements and small feature sets. What do you think?
Thanks.
#Sergey - I think this is just too broad a question for StackOverflow. S.O. isn't a discussion forum; it's a place to go for specific answers. So while your questions are potentially valid, I don't think you should hold out much hope for deep substantive responses here.
May I add, in the friendliest possible way, that your sweeping, unsupported, and negative statements make you look like a troll. You're not a troll are you Sergey?
On the chance that you are in fact authentically concerned, I offer a few quick reactions, particularly as they pertain to Breeze.
Authorization. In Web API you can authorize at the method level. The ApiController base class has a User property that returns the IPrincipal. So whether you have one controller or many (and you can have many in Breeze if you want), the granularity is method level, not just class level.
Memory management. Desktop developers have coped with this concern for years. It may cause you some astonishment if you've always developed traditional web apps where process lifetimes are brief. But long-running processes are not news to those of us who built large apps in desktop technologies such as WinForms, WPF, and Silverlight. The issues and solutions are much the same in the land of HTML and JavaScript.
Layers on the backend. You've been looking at demos too long. Yes most demos dump everything into one project running on one server. We assume you know how to refactor the server to meet scaling, performance and security requirements for your environment. Our demos are concerned mostly with front-end SPA development. We do dabble at the service boundary to show how data flow through a service API, through an ORM, through to the database. We thought it sufficient to identify these distinct layers and leave as an exercise for the reader the comparatively trivial matter of moving these layers to different tiers. We may have to re-visit that assumption someday. But does anyone seriously believe that there are significant obstacles to distributing layers/responsibilities across server-side tiers? Really? Like what?
Unobtrusive validation. When most people start using the word "unobtrusive" in connection with HTML, they are usually making a point about keeping JavaScript out the HTML. Perhaps that's what you mean too, in which case SPA developers everywhere agree ... and that's why there are numerous "unobtrusive validation" libraries available. HTML 5 validation, jQuery validation and Knockout validation come to mind. All of them are in the SPA developer's toolkit and none of them "require developers to use MVC partial views and controllers". What gives you the impression that a SPA would need any server-side resources of any kind to implement validation with JavaScript-free HTML markup?
Ids as security risk. Really? This is bogus. The key value is no more a security risk than any other data value. Millions of applications - not just SPAs - communicate key values to the client, both in the URL and in the body. It's standard in REST APIs. It's standard in ODATA. And you want to dismiss them all by saying that they "target areas with few security requirements and small feature sets"? Good luck with that. I think you'll have to do better than rest your case on a link to a relatively obscure organization's entire web site.
I have built some SPA applications, ranging from small to large (over 100 scripts and views). Only a handful of them had every view accessible to the public. The rest went through a strict access structure. It was so simple to return a 401 unauthorized from the server and the client just handling the 401 to redirect it to the login screen. Mr. Ward and Mr. Papa put it right. Get out of the Demo mode and try to find solutions to the issues you come across. I have watched John Papa's SPA on pluralsight, gone through numerous articles and applications on Breeze and I have to tell you, none of my applications use Breeze to do queries from the client side, because YOU DON'T NEED TO!!
Moreover, I have only extended what I have learnt and come up with my own way of solving problems. This is not an answer to your queries, but I only can provide a short comment. No technique is perfect and there is no ONE way to do everything. My server side is locked down where it needs to be locked down, my routes on the client side are locked down (if using durandal take a look at guardRoute), my scripts are minified and my images are sprited (if there is a word like that). All in all, SPA is a great technique, you got to find solutions to the quirks!
I want to create a dynamic website that does not support IIS. The area where I work does not allow anything to be installed in the server. The have a windows based server and I would like to create a dynamic website. IIS not allowed and server side languages like asp.net, php are not allowed. They did not say anything about client side. Is it possible to do?
In short, a general answer to your question Is it possible? would be No, it's not. And if you still find a way, it's not going to be worth the effort.
For one thing, even without programming languages like ASP.NET or PHP, you still need a web server such as IIS to serve static content. There are of course alternatives to IIS specifically, but no web server at all means no serving web sites at all.
If you would be given an opportunity to server static content, you could possibly produce a web site that is dynamic at least on a per visit basis using client side scripting and cookies, but the things you could make that site do would be very limited, and without anything other than serving static content there is no saving things between sessions, or in any way affecting the server side of the application.
You have to ask yourself why you need to serve this website. Is this something your company would benefit from? If so, could you convince the IT department to setup an environment to serve it? Are there any other alternatives? And, perhaps the most important one: there are lots of free or almost free web hosting solutions out there. Why not just use one of them?
There are many excellent reasons why you would want to create a dynamic website without using a web server. Here are a couple:
You are creating a website as a means of presenting a dataset with hyperlinks that you want to be able to archive on read-only media and ignore for 10 years or more (as you can do with books), and still be able to read (IIS is very poor at backwards compatibility).
You need to present your data to people who have no access to servers or the internet and have no idea how to turn their PC into a web server (there are many millions of such people in the developing world)
Yes, it's challenging, but if you want something to be readable by anyone, anywhere, anytime, and all you can count on are web browsers, there's no option.
By saying you want to do it without IIS, I'm assuming you're implying Apache as well (since you reference no server-side languages).
It depends what you mean by 'dynamic'. Essentially you'll be limited to
JavasScript, which means that you can manipulate information and elements already on the page.
iFrames - this would let you load external pages into elements and pages on the page. These could be dynamic, and if they were on the same server you could manipulate it as well. If it was from an external server, then you wouldn't have control over it from that page.
If you are able to set up an HTTP proxy, you can use JavaScript together with a service like CouchOne. You will need the proxy, since browsers restrict AJAX calls.
I would like to create an app for a myBB forum. So the site on the forum will look nicer and much more cleaner on an iPhone or Android.
Is it possible without an API? It isn't my site ether.
everything is possible, it's just a matter of resources...
technically, you can write an app for everything on the web, but:
an API will tell you how you can do things with the site, without having to reverse engineer all pages/posts/..., and the format of every output resulting from post/get operations. reverse engineering may take a long time, and you will surely not come accross all possible results (error pages, bad authentication...);
an API is quite stable and is always updated with great care from the developpers so as not to break existing applications. without an API, there is no guarantees that your app will not break with the next release of the forum when it is upgraded;
a web API generally defines an output format which is easily parseable: many API outputs XML or JSON, which can be processed with standard libraries. without an API, the output format is plain HTML, which may be difficult to reorganize in order to show the results in a different format.
so, yes, you can definitely write an app for a myBB forum, but it may require a fair amount of work.
You can do, it's called screen scraping and is what was done before XML, the semantic web, SOAP, web services and then JSON apis tried to solve the problem better.
In screen scraping, you grab the site's HTML, parse it, get the data you want out of it, then do what you need with that data. It's more work, and breaks each time the site's layout changes, hence the history of improvements to it.
You mention the site in question is not yours. Many sites do not regard screen scraping as fair use, so check with the site's terms and conditions that you can legally create an app from the data posted there.
you can consider useing HTML5 ... do you think it doable for use app ?