Batch connect pre-populate fields from URI

[cgates]

As I understand it, the batch connect field values are prepopulated based on the last values (as stored in ~/ondemand.../cache/*.json). If field values could be specified as key=value pairs in the URI, it would be possible to create "bookmarks" for different job types. e.g.:

https://blahblahblah/dashboard/batch_connect/sys/arcts_rstudio?auto_accounts=workshop&bc_num_hours=3

To keep things simple, we could say that this is an more advanced usage and so:

1. Presence of any values on the URI means cached values are complete ignored (not read or updated)
2. Any invalid value would show a generic error: 'Invalid field values specified on URI' (or maybe slightly friendlier 'Invalid field values specified on URI:bc_num_hours=-42')

Does that make sense? Happy to clarify.

[johrstrom]

Not directly by what you want (query parameters are on GET requests, these are POST requests with a body).

But I think this feature is what you're looking for - the ability for each user to have named 'saved settings'.

https://osc.github.io/ood-documentation/latest/how-tos/app-development/interactive/saved-settings.html#saving-interactive-application-settings

[cgates]

This is very interesting. UofMichigan has not turned this feature on; I'll follow up with our admins.

Part of the appeal of the query string approach is that it becomes trivial to share a batch connect config with another user. (While uncommon, it's possible to put a query string on a POST request.) Along those lines, is there an easy way to share "saved settings"?
Thanks!

[johrstrom]

Along those lines, is there an easy way to share "saved settings"?

I don't think so. But there's also the authenticity token in these requests to prevent attacks. I.e., you can't force another user to start a job with a malicious link.

[cgates]

Ah - I'm not being clear. I'm not thinking of the the form submission that starts the job. I'm want to pre-populate the form where you configure the job prior to submission. (Image below.)

[johrstrom]

Ah - I'm not being clear. I'm not thinking of the the form submission that starts the job. I'm want to pre-populate the form where you configure the job prior to submission. (Image below.)

Sorry I'm still thinking about query parameters in a GET request. If you inspect the HTML of that form you'll see there's an authenticity_token that's a hidden field. This protects users from CSRF attacks. This is why GET requests with just query parameters won't work - or at least we wouldn't want them to work.

[cgates]

Hi Jeff - sorry for my density and thanks for sticking with me.

I can paste this link into my browser now and it pulls up a lovely batch connect config page:
https://blhblahblah/pun/sys/dashboard/batch_connect/sys/arcts_rstudio/session_contexts/new

I want to paste this link into my browser (same but with query string):
https://blhblahblah/pun/sys/dashboard/batch_connect/sys/arcts_rstudio/session_contexts/new?bc_num_hours=3

Is the CSRF concern above that by extending the page to consider a query string, someone would plug this into the browser:
https://blhblahblah/pun/sys/dashboard/batch_connect/sys/arcts_rstudio/session_contexts/new?authenticity_token=bad

[adnan-umich]

@johrstrom Thanks for your responses and suggestions about saved settings!

To clarify what we're looking for:

1. We want to enable URL parameters to pre-populate (only) the batch connect form fields (not the actual job submission) when accessing the application submission page.

2. Example use case: When I share this URL with a colleague or student:
   https://institution.edu/pun/sys/dashboard/batch_connect/sys/arcts_rstudio/session_contexts/new?bc_num_hours=3&account=workshop

   They should see the form with:

   • Number of hours already set to 3
   • Account already selected as "workshop" (If they have access to it, otherwise it defaults).
   • Other fields would use defaults or be blank

3. This is different from saved settings because:

   • It enables easy sharing of specific configurations via URL
   • Users don't need to save/load configurations manually
   • Particularly useful for workshop/class settings where instructors can share optimized configurations

4. Regarding the CSRF concern - we're only looking to pre-populate the initial form fields when the page loads via GET request, not bypass the form submission security which would still use the authenticity token on POST.

I understand this might require some design considerations, but the functionality would be extremely valuable for our use cases at UMich where we frequently need to share specific configurations with different user groups.