Joe

I think you’re looking at setting a custom field template

howardgrigg

Hi there, just a question about form templating if someones able to point me in the right direction that'd be great! I have a form that generates dropdowns for all the 'Box' objects see:

  1. $fields = new FieldList();
  2. $boxes = CityOnAHill\Inventory\Box::get();
  3. $options = range(0,5);
  4. foreach($boxes as $box){
  5. $boxFields = CompositeField::create();
  6. $boxFields->push(HeaderField::create($box->ID,$box->Number.' - ' . $box->Name));
  7. $boxFields->push(DropdownField::create('A4-'.$box->ID, 'A4', $options));
  8. $boxFields->push(DropdownField::create('A5-'.$box->ID, 'A5', $options));
  9. $boxFields->push(DropdownField::create('Inventory-'.$box->ID, 'Inventory', $options));
  10. $fields->push($boxFields);
  11. };

This works fine and I have the form processing correctly - I just want to tidy up the template to have the form in table rows, as in:

  1. <tr>
  2. <td>Header</td>
  3. <td>Dropdown1</td>
  4. <td>Dropdown2</td>
  5. <td>Dropdown3</td>
  6. </tr>

But when looking at templating forms you seem to need the name of each field but these names are generated based on the IDs.

Ramon Lapenta

Done https://github.com/silverstripe/silverstripe-framework/pull/9427

Show 1 attachment(s)
ramono

The accessibility attribute role="listbox" requires its immediate children to be set as role="option", currently they don't have contain this attribute, which is causing all automated accessibility tests to fail.

Since the role="listbox" is hardcoded into the attributes, I've just added a new entry on the ArrayList for each option that contains a hardcoded value for the attribute.

For a list that does not contain any items, I can see the role="listbox" is still being added, but the respective &lt;li&gt; which announces that there are no options, does not contain the individual option attributes. I could hardcode the role attribute in the template, but seems to me a better option to check in the code of CheckboxsetField.php and OptionsetField.php if the list contains any items before setting the "listbox" role to the list, because the warning that there are no options is not really an option in itself.

Please let me know if the above is acceptable, I can work on it as well.

Thanks

Hide attachment content
(2)
Mo

https://github.com/silverstripe/silverstripe-framework/issues/9346

Show 1 attachment(s)
ekini

Affected Version

at least 4.4

Description

I would expect to see the "Secure" cookie flag set by default for https connections, however without cookie_secure: true in the config it doesn't happen. It's not described in <https://docs.silverstripe.org/en/4/developer_guides/cookies_and_sessions/sessions/#secure-session-cookie|the documentation> and the only way to know it is to look at <https://github.com/silverstripe/silverstripe-framework/blob/b002ef1171f5133735eafbc63d937eeb586c2e01/src/Control/Session.php#L293|the code>

For example, instead of

Set-Cookie: PHPSESSID=&lt;sessionid&gt;; expires=Mon, 29-Oct-2018 21:38:08 GMT; Max-Age=3600; path=/; HttpOnly

I expect to see

Set-Cookie: PHPSESSID=&lt;sessionid&gt;; expires=Mon, 29-Oct-2018 21:38:08 GMT; Max-Age=3600; path=/; Secure; HttpOnly

If I set cookie_secure: true, it renames the default cookie name to SECSESSID, which as a non-standard name can be accidentally exposed, for example in Sentry:
<https://user-images.githubusercontent.com/1527663/70394303-de76e700-1a58-11ea-94c5-dacd7dd8ef1b.jpg|2019-12-09 07 52 10>

So to make it correct I have to add another setting that renames the cookie back:

SilverStripe\Control\Session:
  cookie_secure: true
  cookie_name_secure: 'PHPSESSID'

The above mechanism of renaming the cookie claims it adds another layer of security

> This uses the session_name SECSESSID for https connections instead of the default PHPSESSID. Doing so adds an extra layer of security to your session cookie since you no longer share http and https sessions.

however, with "Secure" flag set, cookies won't be shared between http/https without any extra configuration / code.

Steps to Reproduce

As an example, look at https://www.silverstripe.org/Security/login?BackURL=%2Fadmin%2Fpages|https://www.silverstripe.org/Security/login?BackURL=%2Fadmin%2Fpages which has https but doesn't have "Secure" flag on the cookie.

Proposed solution

Deprecate the setting, change <https://github.com/silverstripe/silverstripe-framework/blob/b002ef1171f5133735eafbc63d937eeb586c2e01/src/Control/Session.php#L293|the line>
to

$secure = Director::is_https($request)

It will make the default installation more secure and remove the code that weakens security (by renaming the session cookie).

Hide attachment content
Ramon Lapenta

☝️ if I add the correct Role to the OptionsetField and CheckboxsetField, my accessibility audits pass with no problem, maybe I should do a PR?

Ramon Lapenta

Does anyone here know if it's on purpose that an OptionSet in SS is generated with a ul that has role="listbox" but then each item doesn't have the correct role?