So I'm following the documentation listed here:
to create a user:
curl "http://localhost:2020/openam/identity/create?
admin=AQIC5wM2LY4SfczmNJCUo6W4qZZmJe8r46C0tWGQ7ZexXUU.*AAJTSQACMDIAAlNLAAoxNzk1NTIyMDEwAAJTMQACMDE.*
&identity_name=testuser
&identity_attribute_names=cn
&identity_attribute_values_cn=Test%20User
&identity_attribute_names=sn
&identity_attribute_values_sn=User
&identity_attribute_names=userpassword
&identity_attribute_values_userpassword=secret12
&identity_realm=%2F
&identity_type=user"
I'm getting a really strange response:
exception.name=java.lang.NullPointerException
what could be happening and how might I debug such an error?
I just tested your call and it works fine for me on OpenAM 11.0.0 so I guess you have some issue with your data store configuration. You may check the deployment container log for exception. Furthermore set debug level to 'message' in OpenAM and have a look in IdRepo debug log. Make sure you understand OpenAM data store / IdRepo and notice that OpenAM is not considered to be an IdM /provisioning tool as IdM only works under limited use-cases. OpenAM is not a web-based frontend to an LDAP Directory Server, IdRepo can be virtually any backend system like an SAP HR system.
Related
I am trying to get Facebook login working with loopback using their loopback-component-passport plugin.
I have configured app details in providers.json and now if I visit http://localhost:3000/auth/facebook I am redirected to facebook and can successfully login. However, when I get redirected back (to /auth/facebook/callback) I get the following error --
ValidationError
422 The 'ApplicationCredential' instance is not valid. Details:providercan't be blank (value: undefined).
I can't make sense of this error because the providers file is where the fb app and paths etc are configured and they are definitely working.
The plugin is poorly documented so I am out of ideas at this point.
I have figured out the cause for this error. I had initiated my loopback project as a blank project. However for loopback-component-passport to work it requires User, AccessToken, ACL models to be available. These are inbuilt in loopback and can be manually added to model-config.json. Or, you can initialize the project with user authentication and it should work.
This was one of many roadblocks that I ran into due to my lack of knowledge in the area and Loopback's poor documentation for the plugin. The Tutorial section in the docs and the example github project it links to are completely out of date.
My application is deployed on IIS 7. I want to check the number of failures as my logic is getting failed at some point and getting errors.Is there any general weblogs in IIS.I can only see system errors in the event logs. Is there any web logs?
Manually trawling the standard W3C logs is ok if you're chasing down requests for certain content types, but they won't tell you an awful lot about why your web application is failing and responding with many 4XX and 5XX status codes. You'll get a status code, but that's about it.
Failed Request Tracing:
Your "go to" diagnostic tool should be the Failed Request Tracing feature that is built into IIS7+.
FRT is one of my favourite features of IIS7/8 for tracking down problems with production sites, especially when debugging apps built on the WebAPI and Ajaxy type stuff.
For more information see:
http://www.iis.net/learn/troubleshoot/using-failed-request-tracing
For example, last week FRT helped me get to the bottom of an issue with a client's hosted site. A particular part of the site (which uses the WebAPI) was failing with a 405 Method Not Allowed status code when making a HTTP DELETE request and despite the DELETE verb being permitted.
Using FRT I was able to generate trace of the failing request which showed me this:
Expanding the "View Trace" entries revealed this error:
The solution for our customer was to disable (it's not used) the WebDAV native module which doesn't permit non-Windows authenticated requests with certain verbs (such as DELETE) to complete. Even if the WebDAV module isn't handling the request it's still in the request pipeline inspecting and validating request headers.
Failed Request Tracing is a really invaluable diagnostic tool, you should learn how to use it.
The HTTPERR Logs:
You should also check the HTTPERR logs located in:
C:\Windows\System32\LogFiles\HTTPERR
If you get 503 - Service Unavailable errors they're a good place to look for clues as to what went wrong if an application pool fails catastrophically, and often.
The is a folder named 'logs' in your 'inetpub' folder where all the logs live. You can look at the Logging tab under IIS in IIS Manager to see the name of the specific log you should check for your site.
I am supporting a web app that uses the DocuSign Connect API to handle signature processing. We are running in production and demo environments (our production environment is using the DocuSign production environment; our demo envrionment is using the DocuSign demo environment).
The interface between my app and DocuSign Connect has been working smoothly for over a year. Sometime in the last week or so, the demo environment began misbehaving. In that time, the production environment has continued to work fine.
The problem is this:
In demo, when a signature event occurs, DocuSign is unable to call our callbackUrl. The failure log indicates the following:
https://[mywebsite]/SignedDocument/DocuSignSignatureEvent :: Error - The request was aborted: Could not create SSL/TLS secure channel.
When I look at my DocuSign Connect Settings, I see a new setting -- "Require Mutual TLS" -- that does not exist in production. I'm not sure if this is related -- I have no idea when this setting was added to the demo environment.
Even though this is a demo app, it poses a problem for us (because our demos no longer completely work). But it poses a much bigger problem if/when this same thing (via a code push or something else) begins happening in production.
Again, this interface has been working fine. Nothing has changed on my web app since the last successful callback occurred (roughly a week ago).
Please try this again, DocuSign Support indicates this should be resolved now.
We've been getting the same error starting today. Nothing has changed recently on our side to affect the demo environment. I'm thinking this might be an issue on DocuSign's end.
I had written a mini App in asp classic this week. It worked perfectly on the test server connecting to the test data base. Then yesterday evening I moved it from the test server to the live server updating the connection strings to the live db.
I published it as an application to the default website in the default app pool. Then I tested it and it worked perfectly.
This morning however both myself and another user receive a 500 -internal Server error when we try and save changes to the database(there appears to be no issue reading from the db) yet my two other collogues have no issue at all.
Even more odd is that the same thing is happening on the test server where the code hasn't been changed in weeks. But this morning I cannot commit to the db from there either.
I have attempt to enable more detailed error tracking and logging but the property options for the server are seem unavailable when i tried to set up custom Active Server Pages (ASP) error pages off online tutorials.
The server is used by a lot of people so I was wondering is their a permission issue depending on the user that restricts writting to the database. Or something else that may have changed to allow some users to write data and others to receive the error.
Im very knew to IIS so it may be something glaringly obvious that I haven't considered.
Thanks
This article should help you:
In earlier versions of IIS, error messages from classic ASP scripts
were sent to a Web browser, by default. Because these error messages
might reveal sensitive information to malicious users, IIS 7 and above
disables this feature by default. When your classic ASP scripts
encounter an error in IIS, you receive the following error message by
default:
An error occurred on the server when processing the URL. Please contact the system administrator.
If you are the system administrator please click here to find out more about this error.
I'm trying to figure out why I'm getting 500 errors in setting up a website in IIS.
So far I've tried the following steps:
Enabled Failed Request Tracing (Doesn't write logs for this site, but
works for other sites)
Enabled detailed error messages. Still Getting the default 500 page
with no additional information.
Give app pool full permission to the project directory.
Made sure app pool was running on classic .NET 2 (old app)
Running the site under a permutation of (Classic/Integrated, .NET
2/4)
Enabled anonymous authentication
So my thinking is, somehow, the site fails before the logging modules are ran.
I suspect this is the case because I see no new entities in Event Viewer, IIS Advanced Logs folder, Or in Failed Request Tracing folder. My only source of information (besides 500 error) is a new entry in the IIS log:
2012-12-04 13:06:05 127.0.0.7 GET / - 80 - 127.0.0.1 Mozilla/5.0+(compatible;.....)
To verify this, is there a way to check which stage of the pipeline a request failed? Is it possible to run the logging modules before the failure occurs?
There is a trace event logger for HTTP.sys. With this you can determine if the request is even making it to the right app pool in IIS. Direction on usage
As a last resort, Microsoft offers a tool called Debug Diagnostic. When you have no other option, use this. It will produce a crash dump of the app pool of your choice. Not easy to go through, but it’s a lead. Direction on usage