Moodle

I agree about ajax popups. See this bug which I opened early November last year: http://tracker.moodle.org/browse/MDL-17146 and has no resolution yet.

box.net still doesn't support dynamically constructing urls. I've already updated the mahara plugin (in my git repository, pending merge to head) to not require session. I talked to Dan about picassa and googledocs, and he's going to update them to not use session as well. Not sure about Flickr, nico wrote that one, I'll have to test it.

I propose adding a new abstract method to the base portfolio_plugin class, supports_multiple_exports (or similar), which defaults to true, but will be overridden for box.net. Then, the portfolio code can support multiple exports per session, but NOT multiple exports of the same type of any plugins which don't support it. Then, we add portfolio/return.php?type=xxxx which box.net (and any other plugins that get written) can use, upon return from authenticating at external system. This figures out the id, and redirects to portfolio/add.php?postcontrol=1&id=xxx to pick up again.

Petr - is this an acceptable solution for you?

Limitation in one plugin is not important imho, they keep improving public APIs in those public services. From my point of view is the most important user experience - is it going to work when users is opening multiple windows each with different course and exports at the same time?

That is what I am aiming for, with the exception of the plugins (only box.net) that don't support it because their external service is unable to handle it. In that case, you can still have an export to mahara in a different tab to an export to box.net - you just can't have two box.net exports in different tabs.

Which raises another question - I've just written some code which allows you to see a list of all current in-progress exports, and either cancel, or continue them.

A situation can happen where the stored sesskey in an export becomes expired. for example:

• start an export
• session dies - browser crashes or whatever
• user tries to restart it but gets a portfolio verification error.

The question is - can we securely work around this case somehow ? Petr do you feel that we can restart an expired export in this case, with a different session key if we ensure that the user is the same?

I do not understand the problem with sesskey, it is stored only in session and is compared when receiving request from browser, it should not be transmitted to other systems or stored anywhere else in DB or session.

It's stored in the exporter object, which persists between requests. It's not transmitted to any other systems. I guess it could be removed from the exporter object and passed along portfolio/add.php each request.

sesskey should be passed with each request and there should not be any true objects in session

not really each request, only those that modify the DB or session - I hope tim explained this in the new security page and everybody understands that now

Yeah I guess I was probably being too clever and trying to encapsulate this by storing it in the export object rather than the calling script.

I think portfolio definitely needs sesskey to prevent users triggering a portfolio request "on behalf of" someone else, but it can be managed better, by using sesskey in the url of portfolio/add.php rather than the export object.

I just wanted to double check that I wasn't hurting security by removing this.

I just committed a huge amount of code to the core portfolio api to deal with this problem.

I need to retest all the different plugins and update them to work with the new api but it seems to be working (multiple exports in different tabs, etc)

Petr can you please review and close this

Petr review ping please!

btw box.net wrote to me about one of these bugs and i suggested they improve their api, so even box.net may be able to support multiple exports per session at some point in the future.

Resolving for now. Any problems can make new bugs or reopen.