API https vs http

[gordong]

Hi all,
I've got this nebulous problem trying to run ajax calls which are
in a Web page file that resides in my Classroom Edition workspace,
that I believe is related to security in the Classroom workspace.

I have a Basic Edition workspace (no security) that runs the same
code without issue, but when I run the file from my Classroom Edition
license, ajax refuses to run and returns an immediate error (that with
no error code - so that doesn't help). (note, I have modified the
coded base workspace domain name and api keys to match the respective
workspaces).

I note that from my basic edition workspace, the URL of the file is:

http://eccask.pbworks.com/f/build_ask_system.html, and when I link to
the file, the same URL is returned to the browser.

However, when I run the file from my classroom edition the URL in my
link is:

http://gordongraber.pbworks.com/f/build_ask_system.html

, but the URL returned to the browser looks substantially different:

https://files.pbworks.com/download/9PI5zAEppB/gordongraber/42010720/build_ask_system.html

I'm not sure why the URL is so different, but I believe the https
protocol is the crux of the issue.

I believe (not sure) the problem is ajax is not allowed to request
data from non secure pages ( the API calls) from a secure page, and
vice versa. I caught this on stackoverflow: "XMLHttpRequests (AJAX
requests) are only permitted on same-origin servers. That means the
scheme://host:port part of the target URL has to match that of the
current document. According to the spec, you shouldn't even be allowed
to make a request on the SSL URL from the non-SSL one."

In the Classroom Edition workspace, I understood that only the login
was secured by SSL. Why is this page being returned through that
protocol? Surely this must be a pbworks system design issue...

Any ideas on how I can resolve this problem?

[gordong]

additional note, now that the problem is becoming clearer:

not only does the protocol change from http to https, but the domain
changes as well. Any of which makes using javascript to perform API
calls from an html file impossible.

The question is, why the free account performs no such redirection,
and the classroom account does?

On Jul 5, 10:48 am, gordong <graber.gor...@gmail.com> wrote:
> Hi all,
>    I've got this nebulous problem trying to run ajax calls which are
> in a Web page file that resides in my Classroom Edition workspace,
> that I believe is related to security in the Classroom workspace.
>
>    I have a Basic Edition workspace (no security) that runs the same
> code without issue, but when I run the file from my Classroom Edition
> license, ajax refuses to run and returns an immediate error (that with
> no error code - so that doesn't help). (note, I have modified the
> coded base workspace domain name and api keys to match the respective
> workspaces).
>
> I note that from my basic edition workspace, the URL of the file is:
>
> http://eccask.pbworks.com/f/build_ask_system.html,  and when I link to
> the file, the same URL is returned to the browser.
>
> However,  when I run the file from my classroom edition the URL in my
> link is:
>
> http://gordongraber.pbworks.com/f/build_ask_system.html
>
> , but the URL returned to the browser looks substantially different:
>

> https://files.pbworks.com/download/9PI5zAEppB/gordongraber/42010720/b...

[Eileen Xie]

This is a security feature that we offer. Because Internet Explorer
will run anything that looks like a script, it's a security issue if a
writer can upload a malicious file to a workspace and get an admin to
run it. Serving the files from a different domain protects you against
malicious access to data on your workspaces. Because it causes
additional load on our servers, this feature is only present on paid
accounts.

[gordong]

Thanks you for the clarification, Eleen!

Well, that doesn't sound right from the cognitive standpoint, for
me... I mean, here is something that would make my tasks easier, and
I can get it in the free edition, but not a paid one? Seems like it
should be an option for paid editions.

Are there not ways of securing the workspace such as putting
restrictions on what users and groups can do? I don't know, but it
seems like it would be possible to set a user preference to redirect
all html files who's author was not an administrator, and let the
admin authored files to run.

Opting out would have the added bonus taking more load off the server.

In our research project, online learning requires students engage in
meaningfully structured activities. Wikis and Discussion forum systems
are generally too loosely structured out of the box and require extra
effort by instructional designers and instructors to guide student
activity. As a result, collaborative learning systems are sometimes
not used as effectively in online education as they could be.

To bridge the lack of features in online learning systems, researchers
and ed. tech. designers have created many systems that support
structured, collaborative learning strategies, such as argumentation,
inquiry learning, and cognitive mapping. All of these systems are
generally narrow in scope - they only address one learning strategy -
or are proprietary in one way or another and therefore not widely
used.

The advent of the Web, Learning Management Systems, open source, and
services such as pbworks, affords a more accessible and generalized
approach to enabling structured learning activity creation and use in
collaborative learning systems. However these systems are still
either, again, to narrowly focused, or so broad, as in the case of
Learning Management systems, that they need to be customized.

In my investigation of wiki systems, pbworks comes out ahead of the
pack first because it's a service that is better than most of what we
could install and run ourselves. The wikis that come with Learning
Management Systems such as Blackboard, Sakai, and Moodle, are dismal
at best. Moving institutional IT departments to install other more
capable open source systems is near impossible, but even then open
source systems would require modification and maintenance. The most
popular Wiki, MediaWiki ( The Wikipedia Wiki ) has almost no user
permissions options, and requires a plugin that would need heavy
modification to be suitable for our needs. TikiWiki has more than
enough permissions features, but is lacking in other ways and would
need modifications. Modifications and maintenance are always a
problem, and again, require cooperation of IT departments.

Pbworks offers a major end run around this mess. It provides a better
feature set than any boxed or online solution I've seen. The API
provides a light weight engine for generating features and information
with absolutely minimal hassle. It would be a definite convenience if
that were achievable in the paid version without having to embed
javascript in a pbworks wiki page!

My research interests are in the area of using available systems for
different structured learning strategies. My idea is that, in
principle, the same underlying collaborative communications engine can
be used to power a wiki, or a structured discussion forum, or a mind
mapping tool. Why reinvent the wheel for each application? In that
vein, pbworks is a viable candidate creating that type of learning
system flexibility.

Thanks again for your support in all of this!

[Jim Puls]

What exactly are you trying to do?

-> jp

--
You received this message because you are subscribed to the Google Groups "PBworks API" group.
To post to this group, send email to pbwik...@googlegroups.com.
To unsubscribe from this group, send email to pbwiki-api+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pbwiki-api?hl=en.