Jump to content

Search the Community

Showing results for tags 'header'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


There are no results to display.


  • Welcome to Smart Mobile Studio
    • News and Information
    • Pre-Sales Questions
    • Smart In the Media
    • Smart Contests
    • Meta
  • Smart Mobile Studio Discussion
    • General
    • IDE
    • RTL
    • Code
    • Client Server
    • Platform
    • Graphics
    • Deployment
    • Suggestion box
  • Smart Mobile Studio support
    • Support
    • Bug report
  • General Discussion
    • Pascal
    • Delphi
    • Javascript
    • HTML/HTML5
    • CSS
  • Resources
    • Website
    • Download Smart Mobile Studio

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL



Company name


Found 3 results

  1. HI. I have this code and works ok (on application declaration unit) FHeader := TW3HeaderControl.Create(Display); FHeader.SetBounds(5, -10, 100, 40); FHeader.Caption := 'xxxxxx'; FHeader.BackButton.Caption := '←'; //arrow left FHeader.NextButton.Caption := '☰'; //hamburger menu FHeader.NextButton.OnClick := createMenu; ... procedure TApplication.CreateMenu(Sender: TObject); begin FfrmMenu := TfrmMenu.Create(Application.Display.View); FfrmMenu.Name := 'MainMenu'; Application.RegisterFormInstance(FfrmMenu, true); Application.GotoForm('MainMenu', feFromRight); Application.GotoForm('MainMenu', feFromRight); end; (the menu appears when i press next button, but the header is visible on login form .) And this one that does not FHeader := TW3HeaderControl.Create(Display); FHeader.SetBounds(5, -10, 100, 40); FHeader.Caption := 'xxxxxx'; FHeader.BackButton.Caption := '←'; //arrow left FHeader.NextButton.Caption := '☰'; //hamburger menu FHeader.NextButton.OnClick := OpenMenu; ... createMenu(Application) procedure TApplication.CreateMenu(Sender: TObject); begin if FfrmMenu = nil then begin ShowMessage('Control 0'); //show message FfrmMenu := TfrmMenu.Create(Application.Display.View); FfrmMenu.Name := 'MainMenu'; Application.RegisterFormInstance(FfrmMenu, true); end; end; procedure TApplication.OpenMenu; begin ShowMessage('Control 1'); //show message Application.GotoForm('MainMenu', feFromRight); //don't show form menu ShowMessage('Control 2'); //show message end; The objective is to open a login form with the header not enabled and, if the password is correct, enable the header and see a menu when clicking on the next button. I do not see what I'm doing wrong
  2. Can support for the iBeacon API be added in the future?
  3. I recently had a look at Scott Helme's site, https://securityheaders.io Scott is involved in information security and his site explains in great detail how to enhance site security by means of http response headers. Quoted : "HTTP Response headers are name-value pairs of strings sent back from a server with the content you requested. They are typically used to transfer technical information like how a browser should cache content, what type of content it is, the software running on the server and much, much more. Increasingly, HTTP Response headers have been used to transmit security policies to the browser. By passing security policies back to the client in this fashion, hosts can ensure a much safer browsing experience for their visitors and also reduce the risk for everyone involved. Let's take a look at some more security based headers. The first step in hardening your HTTP response headers is looking at the additional headers you can utilise to make your site more secure. Outlined below, these headers give the browser more information about how you want it to behave with regards to your site. They can be used to deliver security policies, set configuration options and disable features of the browser you don't want enabled for your site. Once you have setup each header, check it using SecurityHeaders.io." His site features a facility to scan any domain, giving back information on which headers to check. So I scanned a standard SMS project output (Visual Component Projects). The results indicated to add security policies by including the following headers : - Content-Security-Policy - X-Frame-Options - X-XSS-Protection - X-Content-Type-Options The first (Content-Security-Policy) can prevent the browser to load malicious assets by white-listing what is permissible and what is not. The second (X-Frame-Options) can be used to prevent click-jacking by disallowing your website to be framed. The third (X-XSS-Protection) can be used to properly configure the browsers built-in security function (reflective XSS protection) The last (X-Content-Type-Options) reduces exposure to drive-by downloads and the risks of user uploaded content that, with clever naming, could be treated as for instance an executable. Sounds all pretty good to me. The Content-Security-Policy (CSP) is probably the most important. It also comes with a heap of options and the list of permissable resources can be left wide open or screwed down to zero and everything in between. Experimenting a bit I settled on <meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'self' 'unsafe-inline'; style-src 'self' http://yourdomain; img-src 'self' http://yourdomain;"> The first line is the default for 'nothing is permitted'. This will stop the browser from downloading any script, any font, any image, any css file etc. The following lines override this behavious somewhat. The second line handles scripts. The self parameter means that scripts in the same directory as the index file are permissable. Depending on your project linker options either the js is included inline in the html file or a separate 'main'js' file is created which is referenced from the html file (<script type="text/javascript" src="main.js"></script>) The latter is preferred anyway, using inline JS or CSS is considered unsafe as it provides at least an opening for attackers to inject script into a page. Unfortunately the 'external scriptfile' linker option still leaves a small bit of inline js in the html file : <script type="text/javascript"> /* This prevents the window being moved by touches, to give the impression of a native app */ document.ontouchmove = function(e) { e.preventDefault(); } </script> Would be better to include this in the external file as well. For now in both linker options the keyword 'unsafe-inline' is required The third and fourth line handle css-files and images. Since usually the styling info is in a subdirectory (res/app.css) and the images are in a subdirectory as well, the domain must be specified. There are additional parameters to handle for instance http-requests, permissions for audio and video handling and more. The other 3 response headers are valid for all servers but the syntax is slightly dependant on server-type. For nginx servers I believe the following headers are valid : <meta http-equiv="X-Frame-Options" content="'SAMEORIGIN'"> <meta http-equiv="X-Xss-Protection" content="'1; mode=block' always"> <meta http-equiv="X-Content-Type-Options" content="'nosniff' always"> just include these meta tags in the header section of the default.html file in the Templates sub-directory prior to compile and link.
  • Create New...