Closed keithbrinks closed 5 years ago
stevebauman
commented
5 years ago Hey @keithbrinks, this looks like a doozy but I’ll do my best to help and see what’s going on.
When you attempt a login using the LDAP auth driver, what do you see in your Laravel logs before it crashes?
keithbrinks
commented
5 years ago Hi @stevebauman,
Thanks and I'm also cross posting to the sqlsrv repository as well, so depending which side the issue is on, hopefully we can track it down.
It doesn't appear I'm getting much out of the log other than just the connection information:
[2019-04-30 20:00:21] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Binding - Username: venturaapps.admin@venturamfg.local
[2019-04-30 20:00:21] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Bound - Username: venturaapps.admin@venturamfg.local
[2019-04-30 20:00:21] staging.INFO: User 'Keith Brinks' has been successfully found for authentication.
[2019-04-30 20:00:21] staging.INFO: User 'Keith Brinks' is being synchronized.
[2019-04-30 20:00:21] staging.INFO: User 'Keith Brinks' has been successfully synchronized.
[2019-04-30 20:00:21] staging.INFO: User 'Keith Brinks' is authenticating with username: 'CN=Keith Brinks,OU=CKT,OU=Ventura Users,DC=VenturaMFG,DC=local'
[2019-04-30 20:00:21] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Attempting - Username: CN=Keith Brinks,OU=CKT,OU=Ventura Users,DC=VenturaMFG,DC=local
[2019-04-30 20:00:21] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Binding - Username: CN=Keith Brinks,OU=CKT,OU=Ventura Users,DC=VenturaMFG,DC=local
[2019-04-30 20:00:21] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Bound - Username: CN=Keith Brinks,OU=CKT,OU=Ventura Users,DC=VenturaMFG,DC=local
[2019-04-30 20:00:21] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Passed - Username: CN=Keith Brinks,OU=CKT,OU=Ventura Users,DC=VenturaMFG,DC=local
[2019-04-30 20:00:21] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Binding - Username: venturaapps.admin@venturamfg.local
[2019-04-30 20:00:21] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Bound - Username: venturaapps.admin@venturamfg.local
[2019-04-30 20:00:21] staging.INFO: User 'Keith Brinks' has successfully passed LDAP authentication.
[2019-04-30 20:00:21] staging.INFO: User 'Keith Brinks' has been successfully logged in.
[2019-04-30 20:00:22] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Binding - Username: venturaapps.admin@venturamfg.local
[2019-04-30 20:00:22] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Bound - Username: venturaapps.admin@venturamfg.local
[2019-04-30 20:02:00] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Binding - Username: venturaapps.admin@venturamfg.local
[2019-04-30 20:02:00] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Bound - Username: venturaapps.admin@venturamfg.local
[2019-04-30 20:02:02] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Binding - Username: venturaapps.admin@venturamfg.local
[2019-04-30 20:02:02] staging.INFO: LDAP (ldap://172.21.2.211:389) - Connection: - Operation: Adldap\Auth\Events\Bound - Username: venturaapps.admin@venturamfg.local That's everything from the time I logged in, to submitting a POST request.
stevebauman
commented
5 years ago Hmm is your database schema managed by Laravel migrations? And are you able to post your users database table schema?
I'm wondering if this is somehow related to the objectguid column required by Adldap2-Laravel. What datatype did you give the column?
keithbrinks
commented
5 years ago I do manage the database via migrations. When I added the objectguid column I used the following migration:
$table->string('objectguid')->nullable();This is the full schema:
CREATE TABLE [dbo].[app_users](
[id] [int] IDENTITY(1,1) NOT NULL,
[name] [nvarchar](255) NOT NULL,
[email] [nvarchar](255) NOT NULL,
[password] [nvarchar](255) NOT NULL,
[remember_token] [nvarchar](100) NULL,
[created_at] [datetime] NULL,
[updated_at] [datetime] NULL,
[default_division] [int] NULL,
[objectguid] [nvarchar](255) NULL
)But I don't believe this issue is being caused by the objectguid change, as the 502/runtime_error was occurring long before that change was implemented.
stevebauman
commented
5 years ago Ok I see... Definitely strange because this line here in your logs indicate that the user is successfully saved:
[2019-04-30 20:00:21] staging.INFO: User 'Keith Brinks' has been successfully logged in. Which takes place here (after the model save via $user->save()):
Are you using the database session driver?
keithbrinks
commented
5 years ago I'm using the file session driver. But, perhaps I need to clarify the problem. The problem isn't happening (at least specifically) when creating users. Say you already have a user created (like me) and are logged in. Then you go to submit some data. This could be anything. Any form that POSTs data, or I'm also using axios via Vue to send POST requests to an API layer. Both scenarios result in the 502/runtime_error.
For example, I created a simple tests table with two columns: id, and data.
I then created a form to submit data to this table:
<form method="POST" action="/">
{{ csrf_field() }}
<label>Enter Data:</label><br>
<input type="text" name="data">
<p><input type="submit" value="Submit"></p>
</form>Then added a post route to web.php:
Route::post('/', 'DashboardController@store');And implemented the store method:
public function store()
{
\App\Test::Create(['data' => request('data')]);
}So in this example, submitting "test data" results in the 502/runtime_error when signed in with LDAP.
If I am signed out, it works. If I change the auth driver to eloquent and remove the LDAP package via composer, it also works. But as soon as I re-add the LDAP package (even if I keep the auth driver set to eloquent) I get the error.
stevebauman
commented
5 years ago Thanks for clarifying @keithbrinks! Appreciate it. I'm understanding now.
That is definitely bizarre... Do you have model binding enabled via the HasLdapUser trait on your User eloquent model?
One thing you can try is keeping the eloquent driver configured, and disabling the auto_connect option in your config/ldap.php file to see if it's somehow an issue - though connecting still shouldn't happen unless you call upon the Adldap2 facade or use the AdldapInterface in one of your controller methods using dependency injection through Laravel's IoC.
Are you calling Adldap2 anywhere in your application at all? Or just using it for the authentication driver?
I'm surprised this is happening only on POST requests - extremely strange for sure.
keithbrinks
commented
5 years ago Yeah, I don't know what's special about the POST requests, or why it would matter if I'm logged in or not. I wouldn't think LDAP is passing any additional data? Or if it has something to do with the response coming back... Because another point of clarification is that while I do get the 502 error, the data submitted DOES get saved to the database. So it is making it... Which makes me think it's something on the response end.
I do have model binding enabled on User model.
I did as you said with configured the eloquent driver but disabling auto_connect. Same error occurs.
I am using Adldap2 somewhat sporadically. I'm checking if a user object in AD has certain security groups applied to access areas of the application.
stevebauman
commented
5 years ago I do have model binding enabled on User model.
Are you able to remove the model binding trait and test again? You mentioned Vue and API endpoints, are you authenticating via a POST request using Axios and then sending back the returned User model that successfully authenticates?
I'm wondering if this is due to a serialization issue when trying to serialize the LDAP user model that is being set on your User eloquent model on the $ldap property?
keithbrinks
commented
5 years ago Hey @stevebauman, I've gotten some responses on issue opened in the msphpsql repo. See here. Seems like an issue from within macOS.
Though it's still strange that Adldap2 seems to have something to do with it... No idea. But I have a workaround for now, and they'll implement a fix in the driver itself.
I do appreciate the help!
stevebauman
commented
5 years ago No problem at all @keithbrinks! Glad to help in any way I can.
I've gotten some responses on issue opened in the msphpsql repo. See here. Seems like an issue from within macOS.
That's really weird! What a strange issue...
Though it's still strange that Adldap2 seems to have something to do with it...
It definitely seems like that's the case, I'm just so stumped as to what it could be! lol 😅
Does it work okay with the workaround?
keithbrinks
commented
5 years ago Yeah, I followed their instruction to modify the driver and everything has been working like a charm.
I'll go ahead and close this out.
Thanks again!
stevebauman
commented
5 years ago Great, glad you're up and running! No problem at all :smile:
Description:
My application uses SQL Server, for which I use the pdo_sqlsrv driver (https://github.com/Microsoft/msphpsql) to connect. Back in December I was attempting to setup Laravel Valet but kept running into the following error:
At that time I submitted a ticket to the msphpsql repository: https://github.com/Microsoft/msphpsql/issues/909
There's also a couple of tickets in the Microsoft Homebrew ODBC repository: https://github.com/Microsoft/homebrew-mssql-release/issues/25 https://github.com/Microsoft/homebrew-mssql-release/issues/31
Essentially what happens is that I can perform any kind of request to the database (GET, PATCH, DELETE), but when I submit a POST request, the browser gets a 502 error and the error message above gets put in a crash log.
I had believed the issue was related to either the SQLSRV or ODBC drivers, however earlier I wrote a vanilla PHP script to replicate the issue by POSTing data to the database, only that it worked fine.
So I created a fresh Laravel project and created a model to post data to the database. It also worked fine.
So then I when back to my project but I kept getting the 502 error/error above. Only in one circumstance it DID work. I noticed I wasn't logged in.
So through some troubleshooting, I removed the LDAP package, logged in via the Eloquent auth driver, and I was able to send POST requests without issue.
As soon as I re-added the LDAP package, I started getting the 502 errors again.
I'm not sure if there's an issue with this package and how it's somehow interacting with the SQLSRV/ODBC drivers, or if it's an issue on the SQLSRV/ODBC driver side.
Is there a way we can debug this?
Here is the complete crash report:
Steps To Reproduce:
Would be interesting if it's just me, or reproducible by others: