In an alfresco custom webscript, I have a read timeout error, afterwards the alfresco restarts the webscript.
Is possible disable this behaviour?
Related
I've read documentation of wso2am for http access logs in the link https://apim.docs.wso2.com/en/latest/observe/api-manager/monitoring-http-access-logs/
it's written that we should enable http access log only for troubleshooting errors because of performance reason. but i need to log information of every http call( not only for troubleshooting). what is your suggestion?
You can enable the HTTP Access Logs if you are in need to log the incoming API requests in your environment. However, as mentioned in the Docs this will affect the server's performance a little.
If you are looking to log any specific information about the incoming API requests, you can develop a Synapse mediator or a handler and engage with the APIs that you would like to log. You can also, use the same implementation to enable it globally to log the required information for all the API requests which API Manager receives. You can refer to the following sample Log Handler for reference: Custom API Log Handler.
Following are the documentations to write custom mediators and handlers
Writing Custom Handlers
Class Mediator
I'm using the WSO2 Identity Server version 5.3.0. I'm also using WSO2 API Manager 2.1.0.
I created 2 APIs, one which disables the user which by calling the admin service and also an API to enable the user as well. I also created an API to check the user status(disabled/enabled) which checks whether the relevant user is enabled or disabled once the username is entered.
The whole process works fine for a couple of rounds.
disable a user -> check the status(user gets displayed as disabled) -> enable the same user -> check the status(user gets displayed as enabled)
However, if the same user is disabled from a remote computer, the status wrongly gets displayed as enabled and also the user does not get disabled as well. But after I restart the Identity Server, the status gets displayed correctly as disabled and the user is also seen as disabled from the previous API call.
Has this issue got something to do with the cache in Identity Server?
Any suggestive approach to solve this issue is much appreciated. Thanks
From your description, it seems you have more than one node of Identity Server in your deployment. If so, you have to enable clustering in order for the caches to be synced. Otherwise the cache update in node 1 won't be reflected in the node 2 until the cache expiry time reaches (default 15 minutes) or a restart.
Enabling clustering for US 5.3.0
I have implemented Firebase custom authentication using the firebase-admin library in Python on my server.
The first time I use the token, it works fine and I'm able to authenticate.
But if I restart my node.js application a few minutes later, I get the error:
The custom token format is incorrect. Please check the documentation.
Which I believe means that it has expired, even though I never logged out.
This does not seem to be working:
Once you've called authWithCustomToken successfully, you stay logged in forever (until you sign out explicitly) so you should be able to get devices to have a long-lived authentication session without minting long-lived custom tokens.
How do I explicitly save the authentication between application restarts? Or do I have to mint a new custom token on every restart?
Custom tokens are only valid for an hour. However, I'd suspect your caught error code to be something different. I'm personally on a quest to figure out how to best keep these tokens refreshed, but I do wonder if a deployed instance restarting might be an alternate cause of tokens being invalidated.
We've created a windows authenticated sub directory on our web server, however, intermittently when we go there (once logged in as an authenticated user - member of a authenticated group) we get the following error:
Module IIS Web Core
Notification BeginRequest
Handler Not yet determined
Error Code 0x80070005
Config Error Cannot read configuration file due to insufficient permissions
Config File \\?\C:\Inetpub\wwwroot\admin\web.config
Requested URL http://testsite.dev:80/admin
Physical Path C:\Inetpub\wwwroot\testsite\admin
Logon Method Not yet determined
Logon User Not yet determined
The odd thing is once we see this error, hit F5 or refresh and the error goes away, only to reappear a short time later. Very frustrating!!
I have done extensive searches online, but can find nothing. We may also create other sub dirs allowing the same "group" to have access, so this needs to work across all these subs without having to relog in.
We are using IIS7. I've found guides that state for IIS7 ( http://kenno.wordpress.com/2008/10/23/iis7-cannot-read-configuration-file-due-to-insufficient-permissions/ ) but when I do this it seems to then make the directory accessible to all which is clearly not required.
Following my own advice and knowing nothing about the problem, I give you an answer to be accepted or improved upon:
Set IIS_IUSRS to have read access on your windows authenticated directory.—user901820
Configure access in IIS Manager | Your Site | Authentication. Make sure you have disabled "Anonymous Auth" for that folder—this should close it for everyone. If you now enable another Auth method for that folder ... then user should only access it if he provides proper login details.—LazyOne
See Configuring Security at IIS.net.
Can anyone explain why the following happens:
My ASP.NET application requires access to Application event log.
When I access web application initially, it returns "Security" exception (which is expected, as I haven't granted permissions to write to Application event log yet).
Then I give read/write permissions to IIS_IUSRS group on the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog. As a result of this action my web application starts working.
Now I remove those permissions I've granted to IIS_IUSRS group. But
my web application keeps working (although I'd expect "Security" exception raised again)
So, why web application keeps working, although permissions to write to Application log
have been removed?
There is a difference between the permissions required to create an event source in the event log, and the permissions required to write to an existing event source. A higher permission is needed to create the event source.
Here's a source re accessing the event log:
Least privileged accounts have
sufficient permissions to be able to
write records to the event log by
using existing event sources. However,
they do not have sufficient
permissions to create new event
sources.
It could be so that the permission to open the event log is caches as long as you do not restart the ASP.NET application and/or IIS. Depends on how you have done in your code.