Hello,
We have installed Indico on a development server (having an URL starting with https://) in order to prepare and test it before passage to production. We configured some events (conference and meeting), where we would like that the participants register themselves. However, we encounter the following issue with the Registration Form: when someone tries to register as a participant into an event (either as a guest, as a registered user, and even as an administrator), nothing happens : the filled in data is lost. The Form is un-responsive to our tentatives of registering into an event.
The Debug Console indicates a blocking of a Cross-Origin request and an error consisting in loading the template of the registration form – see enclosed screenshot :
.
We have noticed a changing in the indico.conf file: while during the indico setup wizard we have indicated the URL https://events-dev.isae-supaero.fr/ for our Web site, we found in the indico.conf file the value of the BASE_URL variable: https://events-dev.isae.fr/ (which was indicated as an ALIAS in the /etc/httpd/conf.d/indico-sslredir.conf file). Even if we reset manually the BASE_URL variable value (while restarting the uwsgi service), we could notice also the following anomaly in the Console of the browser debugger : at the beginning the form is processed with the firstly mentioned URL, while suddenly it switches to the second URL - see the second screenshot in the next post (since I am limited to one image per post).
We have also noticed that the Query associated with the Submit button is of type POST and has an URL starting with http://, and we cannot understand why. We suppose that the Query is rejected by the browser (because of the http:// instead of https://), and the form data do not reach the server actually, thus the registration is not considered - see the third screenshot in the further post (since I am limited to one image per post).
Could someone please help us to solve this issue, such as to have a well-functioning Registration Form ?
Should you need some complementary information, please do not hesitate to contact me.
Thank you,
Best regards,
Mihaela
The second screenshot referred above is :
Mihaela
Hi again,
Please also note that the mentioned URLs ( https://events-dev.isae-supaero.fr/ and its ALIAS) are not yet accessible on the Web, since we are using a development server for tests.
The third screenshot referred above is :
Hoping that our Indico will enable users to register in different events,
Best regards,
Mihaela
I see a mix of events-dev.isae-supaero.fr and events-dev.isae.fr in your request log. It looks like you are accessing Indico using two URLs - you need to make sure there is only one way to access it (e.g. redirect to the canonical version from any alternative), and that the canonical URL is the one set as BASE_URL.
Also, rm /opt/indico/cache/*.js after changing the config just to be sure the js vars are not cached anymore.
Hello,
That’s exactly the problem that I exposed : it could be noticed this mix in the logs, but in all our configuration the canonical URL is used, with the only exception of the /etc/httpd/conf.d/indico-sslredir.conf file, where the alternate ALIAS was indicated (as ALIAS of the canonical URL).
Why this confusion and this mix in the Indico application, and especially how to fix it ?
I can confirm you that the BASE_URL is well set up on the canonical URL, and we have already removed multiple time the cache, even we have removed multiple times (including hidden files) the installation directory ans started from the scratch - we arrive always in the same blocking point.
What is to be done ?
Thank you.
I guess you did clear your browser cache as well?
Of course, I cleared my browser cache, and even I used multiple browsers to test…
We have even eliminated the declaration of an ALIAS for our site in the indico-sslredir.conf file, and we obtain the same result (after clearing the cache)
There has to be a reference to the wrong URL somewhere… can you search through all the files in /opt/indico/?
grep -r XXX /opt/indico/* should do the job (replace XXX with the wrong hostname)
Hello,
I made two searches, extracting the results in 2 separate files.
The forum don’t enable me to publish links neither to the ISAE-SUPAERO public FTP site, neither to a Google Drive directory. How can I send the 2 files ? By e-mail ? By 2 separate posts on forum ? Please note the file are big. Please find below 2 screenshots of excerpts from the 2 files.
As could be noticed, there are a lot of occurences of HTTP (instead of HTTPS) and of the ALIAS Web address in ISAE (instead of the cannonical Web Address in ISAE-SUPAERO). As the code is generated, we cannot understand how these appear.
Could you locate a path towards resolution ?
Thank you,
Mihaela
Excerpts of the occurences of HTTP
Excerpts of the occurences of the Web adress in ISAE will be in a new post (because of the forum limitations)
I removed the new-user limitations from your forum account so posting links etc. should work now.
Those minified assets do not seem to include anything relevant to your problem, or I can’t see it (I’m sure you agree that searching for a string in an image is not practical ;)).
Hello,
Thank you for granting me an enhanced authorization.
So, I have extracted in the file occur_http.txt all the occurrences of “HTTP” as entire word (since normally we should have HTTPS). As well, in the file occur_isae.txt all the occurrences of “isae” as entire word in the Web address (since normally it should be “isae-supaero”).
Please find above the links towards these 2 files. In the occur_isae.txt there are a lot of logs (I’m not sure that’s interesting), but the first two lines seems to be more interesting as information : could you please look at them attentively ?
Should you need any further information, please do not hesitate to ask me.
Best regards.
Can you please check if https://<yourhostname>/assets/js-vars/global.js contains the correct URL (with https)? Search for "Base": to find the place where the base URL is defined.
If this one is wrong, please:
- check again that there is only one
BASE_URL = '...' entry with the correct URL in your /opt/indico/etc/indico.conf (feel free to paste the config file here in the forum, just remove your SECRET_KEY value first)
-
rm /opt/indico/cache/*.js and restart uwsgi again (to make sure the latest file is used)
- then check
https://<yourhostname>/assets/js-vars/global.js again
Hi again,
Thank you for your availability. The Base appears as correctly defined in the indicated js - please find a copy as txt file at global.js.txt.
The config file has the following content:
# General settings
SQLALCHEMY_DATABASE_URI = 'postgresql:///indico-dev'
SECRET_KEY = ""
BASE_URL = 'https://events-dev.isae-supaero.fr'
CELERY_BROKER = 'redis://127.0.0.1:6379/0'
REDIS_CACHE_URL = 'redis://127.0.0.1:6379/1'
CACHE_BACKEND = 'redis'
DEFAULT_TIMEZONE = 'Europe/Paris'
DEFAULT_LOCALE = 'fr_FR'
ENABLE_ROOMBOOKING = False
CACHE_DIR = '/opt/indico/cache'
TEMP_DIR = '/opt/indico/tmp'
LOG_DIR = '/opt/indico/log'
ASSETS_DIR = '/opt/indico/assets'
STORAGE_BACKENDS = {'default': 'fs:/opt/indico/archive'}
ATTACHMENT_STORAGE = 'default'
# Email settings
SMTP_SERVER = ('smtp.isae.fr', 25)
SMTP_USE_TLS = False
SMTP_LOGIN = ''
SMTP_PASSWORD = ''
SUPPORT_EMAIL = 'unix.si@isae.fr'
PUBLIC_SUPPORT_EMAIL = 'unix.si@isae.fr'
NO_REPLY_EMAIL = 'noreply@isae.fr'
Should you need any further information, please do not hesitate to ask me.
Kind regards.
"Base": "https://events-dev.isae-supaero.fr",
"Login": "http://events-dev.isae-supaero.fr/login/",
So your base URL is set correctly, but the URL Indico sees for incoming requests is wrong. This means there’s a misconfiguration on your web server. Most likely this is because USE_PROXY = True is not set in your indico.conf, so it ignores all the X-Forwarded-* headers indicating the real host/protocol used.
Hello,
Indeed, we discovered a wrong parameter in the configuration file of our Apache Web server : it was actually the setenv. We made multiple tests, it is Ok now. If I understand correctly, the base-url parameter is not really the unique source from which the url of different application pages are generated, there is an alternance between base_url and setenv.
Thanks again for your kind support,
Best regards.
