What is a the difference between Electron flags process.defaultApp and app.isPackaged? Both are used to distinguish dev and production environment. My observation is that Boolean(process.defaultApp) == !app.isPackaged always. Are there any cases, when both are true or both are false?
From doc and code:
process.defaultApp
A Boolean. When app is started by being passed as parameter to the default app, this property is true in the main process, otherwise it is undefined.
app.isPackaged
A Boolean property that returns true if the app is packaged, false otherwise. For many apps, this property can be used to distinguish development and production environments.
From the code - app.isPackaged is set when exec file is not electron or electron.exe.
Note: I know a minor difference is that process.defaultApp may be used in the main process only.
Both can yield the same result, but some extra care has to be taken for the process.defaultApp property:
handle the case where it is undefined (by using the ! operator for instance)
make use of remote.process instead of process in a renderer process
Main process
var isPackaged = !process.defaultApp;
is equivalent to:
var isPackaged = require('electron').app.isPackaged;
Renderer process
var isPackaged = !require('electron').remote.process.defaultApp;
is equivalent to:
var isPackaged = require('electron').remote.app.isPackaged;
Edit:
Some extra information, although not 100% crystal clear, about why the app.isPackaged property had to be added can be found in the related pull request's conversation: add app.isPackaged #12656
Related
We are developing a custom UI5 application.
It is developed in the WebIDE, and therefore deployed as a BSP.
When we use the underlying model for calls ( currently 3, no CRUD ), we chose the path of using ONLY functionimports to communicate with the backend.
All of them work with the POST method.
And all of them work ONLY inside the WebIDE.
Once, I access the BSP URL otherwise, we get HTTP 500 error with "error while requesting the ressource.
We already created links, to enable special portfowarding, no result.
Let's stick to my URL from the BSP first.
I paste it into my 3 browsers: 500.
We also created a special non dialogue-user with proper roles and permissions, and in the SICF tree we assigned it .
Again, when calling from inside the WebIDE, the functionimport-calls work, otherwise not.
Error-Logs are empty.
Dumps do not happen.
ST05 trace shows where 500 is passed, deeply inside the HTTP framework, yet no chance to spot the code location, neither a breaktpoint.
In SICF logon-settings we have:
Types all, also flagged "all", SAML: inherited from parent node, sec-sessions Not limited, fix user and pw, sec: Standard, auth:Standard Sap user.
The gui-options contain ONLY one flag: ~CHECK_CSRF_TOKEN 0.
In my client I use :
Where the model is initialized as :
function initModelV2() {
var sUrl = "/sap/opu/odata/sap/Z_this_is_a_company_secret_service/";
var oModel = new sap.ui.model.odata.v2.ODataModel(sUrl);
sap.ui.getCore().setModel(oModel);
}
What else can I do to get "at least closer" to the reason, WHY ?
I could solve it, and believe it or not, sometimes simple logic helps.
I debugged the backend of CL_HTTP_RESPONSE, and once I saw, GET_STATUS, I thought to look for SET_STATUS.
There it was:
this.rModel.setHeaders( {"X-Requested-With" : "X" } );
Was missing.
Though I set it in the manifest of my model, it was not passed.
Once set in the code, it worked.
I wonder, why it is not accepted in manifest.
I have an assumption.
1st: I have this in my manifest ( yellow arrow shows, where i HAD it set up before):
But I also have an instantiation in my code, in servicebindings.js with this code
Can it be, that, in the end, I have accidently created 2 models ?
I'm making a very simple Delphi console application ({$APPTYPE CONSOLE}) with a single TChromiumWindow on the main form. The purpose of the application is to retrieve a webpage, process the HTML and output some JSON to the console. This can not be done using plain HTTP requests due to the nature of the webpage, which requires running some javascript as well.
Everything works as expected, except for one problem. The chromium components output some error messages to the console as well, which makes my JSON invalid! For example, I always get the following two error messages on startup:
[0529/133941.811:ERROR:gpu_process_transport_factory.cc(990)] Lost UI shared context.
[0529/133941.832:ERROR:url_request_context_getter_impl.cc(130)] Cannot use V8 Proxy resolver in single process mode.
Of course the best solution would be to not get any error messages in the first place, but for several reasons (which mostly have to do with company legacy code) I can't for example disable single process mode.
So the next best thing would be to keep these error messages from being printed to the console. I've tried setting
GlobalCEFApp.LogSeverity := LOGSEVERITY_DISABLE;
but that didn't help. Specifying a logfile using GlobalCEFApp.LogFile doesn't help either.
So how can I prevent the Chromium components from writing to the console at all?
The TChromium component provides an OnConsoleMessage event with signature :
TOnConsoleMessage = procedure(Sender: TObject; const browser: ICefBrowser;
const message, source: ustring; line: Integer;
out Result: Boolean) of object;
If you handle this event and set the Result variable to true the message output to the console is suppressed.
Set LogSeverity to LogSeverity.Fatal or n other desired.
var settings = new CefSettings()
{
//By default CefSharp will use an in-memory cache, you need to specify a Cache Folder to persist data
CachePath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), "CefSharp\\Cache"),
//Set log severity to showup only fatal errors.
LogSeverity = LogSeverity.Fatal,
};
//Autoshutdown when closing
CefSharpSettings.ShutdownOnExit = true;
//Perform dependency check to make sure all relevant resources are in our output directory.
Cef.Initialize(settings, performDependencyCheck: true, browserProcessHandler: null);
I am aware of two methods of determining whether my app is in running in debug mode:
const bool.fromEnvironment("dart.vm.product") returns true if release.
And this from the Sentry part of the Flutter docs:
bool get isInDebugMode {
// Assume we're in production mode
bool inDebugMode = false;
// Assert expressions are only evaluated during development. They are ignored
// in production. Therefore, this code will only turn `inDebugMode` to true
// in our development environments!
assert(inDebugMode = true);
return inDebugMode;
}
Are those two always equivalent or are there situations where they would give different answers? Which should I use? The first method being compile time seems to favour it.
In general they should be the same, but there can be differences.
const bool.fromEnvironment("dart.vm.product") depends on release build being performed. I haven't checked if profile build returns true or false
assert(inDebugMode = true); depends on asserts being enabled.
asserts are enabled in debug mode by default and disabled in release builds by default but there should be a way to enable/disable asserts independently of release/debug mode, but I haven't found how. Perhaps it's not exposed in Flutter or it is not implemented in Dart yet.
I'd think bool.fromEnvironment() works better with tree-shaking because it can be used to create a const value.
We have a legacy application running on Oracle Application Server J2EE 10g 10.1.3.5.0 using OC4J containers. To clear a Veracode dynamic scan flaw CWE ID-402 (and for best practice) we need to set the HttpOnly flag on our JSESSIONID cookies. We found, albeit scant, documentation for a system property:
-Dhttp.response.httponly=true
That supposedly supports this. (Some details on all supported properties here, although you may want to run it through a translator: https://volbers.wordpress.com/2011/06/24/secrets-of-the-oc4j/)
What we found, however, is that while this property works in a stand-alone OC4J instance (e.g., running in Eclipse), it does not work when deployed under OAS/OPMN. We even tried using reflection to lookup the Evermind OC4JProperty for HTTP_RESPONSE_HTTPONLY and were able to set it to true programmatically. However, the same behaviors ensued: Something is ignoring that property when running in the deployed container.
Does anyone know how to make this work in a deployed environment?
Just for context, here is OC4J's own description of this property:
% java -jar /oas/j2ee/home/oc4j.jar -describeProperty http.response.httponly
Property name: http.response.httponly
Description: Used to prevent cross-site scripting attack
Default value: false
Primitive type: Boolean
Deprecated: false
Log value change: false
Is static: false
Try adding the following to your orion-web.xml
<session-tracking cookie-path="/pathtoyourapp; HttpOnly"/>
I'm using rack mini profiler in rails just fine, but during some coding sessions especially where I'm working on a lot of different client side code, it gets in the way. (mainly in my client side debugging tools network graphs, etc.)
I'm trying to turn it off with a before filter, that also serves to see if the user is authorized to see the profile anyway, but "deauthorize" doesn't seem to do anything for me. Here's my code called as a before filter:
def miniprofiler
off = true
if off || !current_user
Rack::MiniProfiler.deauthorize_request
return
elsif current_user.role_symbols.include?(:view_page_profiles)
Rack::MiniProfiler.authorize_request
return
end
Rack::MiniProfiler.deauthorize_request
end
I also know there is a setting "Rack::MiniProfiler.config.authorization_mode" but I can't find docs on what the possible settings are, and not seeing it used in the code? Right now its telling me :allow_all, but :allow_none doesn't do anything either.
Even if I can just temporarily set a value in the dev environment file and restart the server, that would serve my purposes.
Get latest and type:
http://mysite.com?pp=disable
When you are done type
http://mysite.com?pp=enable
See ?pp=help for all the options:
Append the following to your query string:
pp=help : display this screen
pp=env : display the rack environment
pp=skip : skip mini profiler for this request
pp=no-backtrace : don't collect stack traces from all the SQL executed (sticky, use pp=normal-backtrace to enable)
pp=normal-backtrace (*) : collect stack traces from all the SQL executed and filter normally
pp=full-backtrace : enable full backtraces for SQL executed (use pp=normal-backtrace to disable)
pp=sample : sample stack traces and return a report isolating heavy usage (experimental works best with the stacktrace gem)
pp=disable : disable profiling for this session
pp=enable : enable profiling for this session (if previously disabled)
pp=profile-gc: perform gc profiling on this request, analyzes ObjectSpace generated by request (ruby 1.9.3 only)
pp=profile-gc-time: perform built-in gc profiling on this request (ruby 1.9.3 only)
You can also use Alt + p to toggle on Windows/Linux and Option + p on MacOS.
If you want the profiler to be disabled initially, and then activate on demand... add a pre-authorize callback in an initializer file like:
Rack::MiniProfiler.config.pre_authorize_cb = lambda {|env| ENV['RACK_MINI_PROFILER'] == 'on'}
then in your application controller, add a before_filter that looks for the pp param
before_filter :activate_profiler
def activate_profiler
ENV['RACK_MINI_PROFILER'] = 'on' if params['pp']
ENV['RACK_MINI_PROFILER'] = 'off' if params['pp'] == 'disabled'
end
your environment will not have RACK_MINI_PROFILER set initially, but if you want to turn it on, you can tack ?pp=enabled onto your url. Then you can disable again later (the pp=disabled will only turn it off for the current session, but setting the ENV variable to off will kill it entirely until you force it back on).