| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
(cherry picked from commit 7067e174c27a1fe9b23d13806f1e52ce9bc2aaee)
|
|
|
|
| |
(cherry picked from commit f5d762f90924510c097a9065dff135dab01f46f0)
|
|
|
|
| |
(cherry picked from commit 718b3b0b1b75de09a87866cb37b5a0752643283a)
|
|
|
|
| |
(cherry picked from commit 75a1149e0104561446e6f90f98d98c6c13c52996)
|
|
|
|
| |
(cherry picked from commit 27bc5848cfea95f97f70a4fe0c30da6319794a9a)
|
| |
|
|
|
|
| |
and for all IPv6 items
|
| |
|
|
|
|
|
|
| |
work properly. OpenSSL claims it's not valid ("unknown signature algorithm"). Fixes #7370
While I'm here, stop needlessly repeating the algo list, it's a global in certs.inc, so use that single copy of the list.
|
|
|
|
| |
Found this while looking into ticket #7370
|
|
|
|
| |
(cherry picked from commit 294f14f7897f973f1fa2a1506cfdd9117b5daf65)
|
|
|
|
|
|
| |
the domain in the GUI to update the domain's @ record. Then in the backend code, remove that from the FQDN since CloudFlare doesn't like that to be sent explicitly. Fixes #7357
Fix is confirmed to work by two forum users: https://forum.pfsense.org/index.php?topic=122099.msg699763#msg699763
|
|
|
|
| |
Fixes #7356
|
| |
|
|
|
|
| |
admin account is expired and reset if needed. Fixes #7354
|
|
|
|
| |
(cherry picked from commit 9c91c7bd747074b8cdaa90e8810f0c2df081f72d)
|
| |
|
|
|
|
|
|
|
|
|
| |
As far as I can see, filter_generate_user_rule() is always supposed to be called with 'ipprotocol' set to 'inet' or 'inet6'. The cases of rules for both ('inet46') are handled by calling filter_generate_user_rule() twice, passing 'inet' then 'inet6'.
So at this point, if 'ipprotocol' is blank, then it is from an old rule, and it [can|should|must] default to 'inet'.
This would provide a generic fix for old rules that do not have 'ipprotocol' specified.
The other thing that could be done is make some upgrade code that fills in 'ipprotocol' on old rules at upgrade.
|
|
|
|
|
|
|
| |
HTML tags not allowed in selector option values
(cherry picked from commit 57f4327a60c0cabf43161a6cfde98479b42a7092)
(cherry picked from commit 8dbde62f220234c8fcfe472b97cdba606779bc22)
|
|\ |
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Time to RELEASE
This reverts commit 2722f4c257ddd532ad31a4851c4580b3bd667482.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Some widgets create extra panels, e.g. the widgets that now have the filter functionality. Those panels are processed in the ".each" at line 424. They do not have an id in the form "widget-*" and when the old code tries to find the "*" part it gets "undefined". This results in the layout being saved like:
```
<sequence>interface_statistics:col1:open,undefined:col1:close,system_information:col2:open,undefined:col2:close,picture:col3:open,rss:col3:open,ntp_status:col2:open</sequence>
```
This PR puts extra checks in place so that the "undefined" stuff does not get written into the widget sequence string.
(cherry picked from commit 621dd53615f14f5732a347346b4b8444e81ea97f)
|
|
|
|
|
|
| |
Selecting 1,2,3,4 or 6 dashboards columns results in an exact integer result here and all is good. But 5 columns results in "2.4" and "col-sm-2.4" is not a thing in bootstrap.
We need just the best int we can choose here, which is one that is just the int part of the division. That ensures that the 5 columns extend over less than the standard bootstrap total of 12 "units" wide.
(cherry picked from commit d86cff7f61af51ee2bd9df9df309576b11d7ecc6)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Fix #7051
This reverts commit 04665e78537906f7375668ca665cba17f95a4864.
|
|
|
|
| |
This reverts commit c7c79905d3e0fd01172d373a15a1d0d77a5728e8.
|
|
|
|
| |
(cherry picked from commit 7abc3f992e5dd5bff53495844ce944163d6d1d9b)
|
|
|
|
|
|
|
|
|
|
|
| |
In some places ldap_get_groups has:
```
return memberof;
```
It should have the "$" in front, so it will return the $memberof array (that is empty when this happens).
This causes issues for callers that expect to have a return value that is either false, an empty array, or an array of the groups.
(cherry picked from commit 0241b34f1a33c3ae83fdf817c8c374b10775335a)
|
|
|
|
| |
(cherry picked from commit e4488e51cf424907e06ef7cc73370aa0657e5e25)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When there is an upgrade, the echo here was outputting a stale value of the version. For example, on first upgrade from 2.3.3-DEVELOPMENT to 2.3.3-RC the console had:
pfSense (pfSense) 2.3.3-DEVELOPMENT amd6 Sat Feb 11 14:24:27 CST 2017
Bootup complete
FreeBSD/amd64 (myhost.localdomain) (ttyv0)
*** Welcome to pfSense 2.3.3-RC (amd64 full-install) on myhost ***
That is a bit confusing for users to be sure which version it is at this point.
(cherry picked from commit c0044174800c3b509dd79906aeaf69e4c6ff1385)
|
| |
|
| |
|
| |
|
| |
|
| |
|