password is hashed and I can log in with the user
password is not hashed in database and I cannot log in with that user
I am operating my site on Amazon EC2 with IIS and a mysql-database.
I have different things in my site - so here is how I sort of 'interlace-configured' Directus:
My web-config looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<remove name="WebDAV" />
<remove name="PHP" />
<add name="PHP" path="*.php" verb="GET, PUT, POST, DELETE, PATCH, HEAD" modules="FastCgiModule" scriptProcessor="C:\Program Files (x86)\php\php-cgi.exe" resourceType="Unspecified" requireAccess="Script" />
</handlers>
<rewrite>
<rules>
<clear />
<rule name="cImported Rule 1-1" enabled="true" stopProcessing="true">
<match url="^c/assets" />
<action type="None" />
</rule>
<rule name="cImported Rule 2" enabled="true" stopProcessing="true">
<match url="^c/extensions/([^/]+)" />
<action type="None" />
</rule>
<rule name="cImported Rule 3" enabled="true" stopProcessing="true">
<match url="^c/extensions/([^/]+)/assets" />
<action type="None" />
</rule>
<rule name="cImported Rule 4" enabled="true" stopProcessing="true">
<match url="^c/extensions/([^/]+)/main.js" />
<action type="None" />
</rule>
<rule name="cImported Rule 5" enabled="true" stopProcessing="true">
<match url="^c/listviews/([^/]+)" />
<action type="None" />
</rule>
<rule name="cImported Rule 6" enabled="true" stopProcessing="true">
<match url="^c/listviews/([^/]+)/assets" />
<action type="None" />
</rule>
<rule name="cImported Rule 7" enabled="true" stopProcessing="true">
<match url="^c/listviews/([^/]+)/ListView.js" />
<action type="None" />
</rule>
<rule name="crule 2V" enabled="true" stopProcessing="true">
<match url="^c/api/extensions/([^/]+)" />
<action type="Rewrite" url="c/api/api.php?run_extension={R:1}&%{QUERY_STRING}" />
</rule>
<rule name="crule 3V" enabled="true" stopProcessing="true">
<match url="^c/api" />
<action type="Rewrite" url="c/api/api.php?run_api_router=1&%{QUERY_STRING}" />
</rule>
<rule name="cDynamicContent" enabled="true">
<match url="^c/(.*)" ignoreCase="true" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" />
</conditions>
<action type="Rewrite" url="c/index.php" />
</rule>
</rules>
</rewrite>
<security>
<requestFiltering>
<verbs allowUnlisted="false">
<add verb="GET" allowed="true" />
<add verb="POST" allowed="true" />
<add verb="DELETE" allowed="true" />
<add verb="PUT" allowed="true" />
<add verb="PATCH" allowed="true" />
<add verb="HEAD" allowed="true" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
<location path="c">
</location>
</configuration>
I can create users in general and create/delete/change collections, however the configuration was fully manual.
In the C:\inetpub\wwwroot\a\config\api.php those strings are still on default, simply because I do not know how render those strings in a way, that they fit together:
'auth' => [
'secret_key' => '<type-a-secret-authentication-key-string>',
'public_key' => '<type-a-public-authentication-key-string>',
Did you try these steps?
I am impressed - THANK YOU.
The DB Upgrade helped a great deal and I did not naturally think to do it like this.
Interestingly since this is a virgin setup I reapplied the newest schema.sql (which recreates tables). After that the passwords were still created unhashed in the database - so it seems that your DB Upgrade is needed even for new installs. Maybe you can add that to the documentation of the manual install process... Anyway, do not want to complain - just thank you.
Thanks @Derilka — glad that worked out!
@bjgajjar — this issue should have been resolved in the last release. We need to make sure that schema.sql is clean now, so let's re-generate it... and then we need to make sure that it gets updated whenever migrations change.
@rijkvanzanten — can we add "build boilerplate SQL" to the deploy/release docs?
the schema should be updated whenever a migration is made, not when the api is released
Most helpful comment
I am impressed - THANK YOU.
The DB Upgrade helped a great deal and I did not naturally think to do it like this.
Interestingly since this is a virgin setup I reapplied the newest schema.sql (which recreates tables). After that the passwords were still created unhashed in the database - so it seems that your DB Upgrade is needed even for new installs. Maybe you can add that to the documentation of the manual install process... Anyway, do not want to complain - just thank you.