Add authentication options for import

[jjeising]

This adds options for HTTP basic auth and a user definable Authentication header for import.

Authentication options are currently reused when repeating an import, but are not changeable or viewable.

[zuntrax]

When you create a new import with "No Authentication" selected, the following error occurs:

Server error
InvalidDataException

ERROR: invalid input value for enum enum_import_auth_type: ""

[jjeising]

When you create a new import with "No Authentication" selected, the following error occurs:

Thanks for testing and reporting!

This issue occurs because we currently don't handle this field as Database::TYPE_ENUM because information_schema.columns.data_type is USER-DEFINED:

    array (size=6)
      'column_name' => string 'auth_type' (length=9)
      'data_type' => string 'USER-DEFINED' (length=12)
      'is_nullable' => string 'YES' (length=3)
      'column_default' => null
      'character_maximum_length' => null
      'numeric_precision' => null

We should improve handling here, set the type and add available enum options, like we do for MySQL. @pegro Can you give some PostgreSQL insight here?

The other change that would fix this the option to nullify blank string values (string is the fallback type here) in newer framework versions. But this is an additional Model option, so it is less desirable.

[pegro]

You could check the value in information_schema.columns.udt_name for user-defined types, as mentioned in the documentation (https://www.postgresql.org/docs/current/static/infoschema-columns.html). Does it contain something you could use? If you don't want to add PHP code for that you could extend the query and use CASE WHEN data_type = 'USER-DEFINED' THEN udt_name ELSE data_type END AS data_type

[jjeising]

Does it contain something you could use?

udt_name gives enum_import_auth_type – this is not very useful, especially since the name does not have to contain enum. As far, as I understand need need to adapt the query for PostgreSQL. This isn't a problem, as PostgreSQL and MySQL already have separate queries and handling (we use SHOW COLUMNS… for MySQL). enum_range() looks nice, but I'm not sure if it supports string field names. In the end we probably need to query pg_ tables, ideally producing a more or less similar result to MySQL (type enum and a field with comma separated values (or a more useful data format)).

[a-tze]

Improving the framework is a good idea.. but what about changing the auth_type column to not null default 'none' and add 'none' as enum value?

[jjeising]

but what about changing the auth_type column to not null default 'none' and add 'none' as enum value?

I'm not quite sure what I think about none. We would also have to set this value in the dropdown, otherwise we would still send an empty string.

[jjeising]

@pegro I've created an issue with a new query, if you would like to have a look.

[jjeising]

Fixed issue with enums, would merge now. Any objections @pegro, @a-tze ?

[pegro]

No ;)