I'm trying to create a web.config file for security on an intranet.
I want it to have the following rules:
If someone browses to the site on a specific IP range, they get
straight in.
If someone doesn't fall into that IP range, they are presented with
a log in box that authenticates against an LDAP query.
I have gone down the route so far of the following method for IP access and it works fine.
<security>
<ipSecurity allowUnlisted="false">
<add ipAddress="x.x.x.0" subnetMask="255.255.255.0" allowed="true"/>
</ipSecurity>
</security>
<modules runAllManagedModulesForAllRequests="true"/>
How could I then combine this with LDAP authentication (if that's even possible)? Or should I take a different approach? My only concern so far is that the ipsecurity method is too specific and you are either allowed in or you're not with no room for another form of authentication.
Any tips would be much appreciated!
Thanks in advance,
Tom
Related
Here is the setup: migrating a page that takes an encrypted string from a query string and processes it to redirect to the wanted page.
The problem: The querystring is too long (8760) and the result goes to a page not found but if I truncate the encrypted string it to a much shorter length (2035 or less), it goes through, but of course it does not process)
More info: I have so far added in the keys
<httpRuntime targetFramework="4.6.1" maxRequestLength="2097151" waitChangeNotification="1" maxWaitChangeNotification="3600" requestValidationMode="2.0" maxQueryStringLength="32768" maxUrlLength="65536" enable="true"/>
I am at a loss, and can only think there is some sort of hidden setting that I am missing but cannot figure it out.
The sample URL I am useing (to give you an idea of the length is:
http://localhost:1112/SSO/Consume?SAMLResponse=PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIENvbnNlbnQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpjb25zZW50OnVuc3BlY2lmaWVkIiBEZXN0aW5hdGlvbj0iaHR0cHM6Ly93ZWxsdG9rLnF1aXRsb2dpeC5vcmcvU1NPL0NvbnN1bWUuYXNweCIgSUQ9Il9kNjllMDk4ZjNjZDMzMWRkY2M0MGU2NmRhMzE5MDBhMiIgSXNzdWVJbnN0YW50PSIyMDIwLTEwLTIyVDIzOjU5OjQwWiIgVmVyc2lvbj0iMi4wIj48SXNzdWVyIHhtbG5zPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj5odHRwczovL2NhZmV3ZWxsLmNvbTwvSXNzdWVyPjxzYW1scDpTdGF0dXM+PHNhbWxwOlN0YXR1c0NvZGUgVmFsdWU9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpzdGF0dXM6U3VjY2VzcyIvPjwvc2FtbHA6U3RhdHVzPjxzYW1sOkFzc2VydGlvbiB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIiBJRD0iXzViOTNhZTQ3ZDNiYzJhYjRkNDY5YjEzNWViODE0ZjUxIiBJc3N1ZUluc3RhbnQ9IjIwMjAtMTAtMjJUMjM6NTk6NDBaIiBWZXJzaW9uPSIyLjAiPjxzYW1sOklzc3Vlcj5odHRwczovL2NhZmV3ZWxsLmNvbTwvc2FtbDpJc3N1ZXI+PGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlNpZ25lZEluZm8geG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPjxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIj48L2RzOkNhbm9uaWNhbGl6YXRpb25NZXRob2Q+PGRzOlNpZ25hdHVyZU1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNyc2Etc2hhMSI+PC9kczpTaWduYXR1cmVNZXRob2Q+PGRzOlJlZmVyZW5jZSBVUkk9IiNfNWI5M2FlNDdkM2JjMmFiNGQ0NjliMTM1ZWI4MTRmNTEiPjxkczpUcmFuc2Zvcm1zPjxkczpUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZW52ZWxvcGVkLXNpZ25hdHVyZSI+PC9kczpUcmFuc2Zvcm0+PGRzOlRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMTAveG1sLWV4Yy1jMTRuIyI+PC9kczpUcmFuc2Zvcm0+PC9kczpUcmFuc2Zvcm1zPjxkczpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjc2hhMSI+PC9kczpEaWdlc3RNZXRob2Q+PGRzOkRpZ2VzdFZhbHVlPmtNUWdSanR4TDZqVUdrN3NoRGJ3MUFuMFZRTT08L2RzOkRpZ2VzdFZhbHVlPjwvZHM6UmVmZXJlbmNlPjwvZHM6U2lnbmVkSW5mbz48ZHM6U2lnbmF0dXJlVmFsdWU+WEZJMHFkSjNVWXpCS0VETFR2Y3VXbjhCcnEzY3Izc0p5T3lBZGZsN2J5K0IrSnN2OVpYeTRFQ0tIaUlVSVV2K2RJRHFwaDNDc3o1OUdQcFZnekdNcmNVNFFlYmlnYlhMVm92TkNUQVY1dFlWQWI2TnlSbFp5cW9qRld3dEZMdFhqUzZva1ZmYTFkelJSSXZGSnJTTjVYQS85WVNNTXRaQlhsSlVCelpYaEdVdVlyOFZJNGh3aWpBaWpUNDdzQm9Wbk85b2taNUJ2cXYrMXZZaFVGZEJINktPaEc0d0lIbXEwOForSTZ3L0V3Z3V2MThYdk9pbUhidkkvWTV3NkJTb0owNnl6cGZxR0lXVmZ3MVBnTjNwdGJpZE9icGdId0VtS0pqNFdlVk9ZOGQwUk4xazN6Mk5LQitqQzFmakZvT3hFd2FQQTlhd0U0RDNiSmc1UXZaSGRzQTBwVmFLazQxODJQK0hGR0FyUUdYZVcvNnNraTVHVVhYc2tOTXFUTDZnZG9iNWYreHVoc3VjTmx2TjltT3ZzR1NFR3lLVzZ3U3BQVkJrQko4SE44ZWZ0a2FBRFVQOFJWaGdFZ3pmenlibHRRNlVqMEZRbS9wZkJFV1FQRGl5dm5Ia25CRVlab2E5TDZvRnZTL2lNQURXSjNNZk40MHV4NUVCSVdmdWp4ZzhBZjhjYi9qSEpucTF5S1JPQ0ZXM2drOGNaNmdFazZNZ1dySDVYSCtFWmx6YjZ0Ym5KdEZTOVdIa1Fic1pCdkpXRzhrSUEwOUM5T3FzUmdBemVub2lUK0k0U0UvTURBcFRNcE0vREJITm5qNVZYeFR0LzU1V1cyQWtUWU1hWWQwckY3NFNvbDRCZUpGL0ZlL2dMdm8wMXBLWDN4U3BTUlphbTdJRWNHSkM2T1E9PC9kczpTaWduYXR1cmVWYWx1ZT48S2V5SW5mbyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlg1MDlEYXRhPjxkczpYNTA5Q2VydGlmaWNhdGU+TUlJSVp6Q0NCMCtnQXdJQkFnSVFDODBLZGRMd0MvVURLK2VodWtoWUNqQU5CZ2txaGtpRzl3MEJBUXNGQURCd01Rc3dDUVlEVlFRR0V3SlZVekVWTUJNR0ExVUVDaE1NUkdsbmFVTmxjblFnU1c1ak1Sa3dGd1lEVlFRTEV4QjNkM2N1WkdsbmFXTmxjblF1WTI5dE1TOHdMUVlEVlFRREV5WkVhV2RwUTJWeWRDQlRTRUV5SUVocFoyZ2dRWE56ZFhKaGJtTmxJRk5sY25abGNpQkRRVEFlRncweU1EQXpNRFF3TURBd01EQmFGdzB5TWpBMk1EY3dNREF3TURCYU1HSXhDekFKQmdOVkJBWVRBbFZUTVJFd0R3WURWUVFJRXdoRGIyeHZjbUZrYnpFUE1BMEdBMVVFQnhNR1JHVnVkbVZ5TVJZd0ZBWURWUVFLRXcxWFpXeHNkRzlyTENCSmJtTXVNUmN3RlFZRFZRUUREQTRxTG1OaFptVjNaV3hzTG1OdmJUQ0NBaUl3RFFZSktvWklodmNOQVFFQkJRQURnZ0lQQURDQ0Fnb0NnZ0lCQU1HSFpyOSs5R0w5Vy9ZYjRoL2E0OGJMUU9KVzRySFpJcjhHYVVwRFZabEtrS2laeHcvVWZVUVc1RFNkU0hTWGRaYVRVZ0xUejA2ekhza1JHd0l3cW5ENXp4M0hjT1YyRVdhRCtITGFhTjRBMkJVU0JHQzBkUjdJZHg2eXFFeXp0YWc3S3k2TFhSNlVqbHJqSjA4NDJlVVNud0YrTnNWcWNBSG4yMzJlOGZENno0QTFwN2o4T1NkRmxiOEJmdjFmRVgzeFQwZGNBQmdrZ0orL1Zzdm56anZPWmZRQStxL1BPZVpwNWN3TE1Ed2daWWtiNUFIbUJxMEVXUHR2RmtHci9iNW1LdXVvcUxmeTlzbVR2NHJ2SlJ0dDJOMW5RRTZ6dnlLMjlzVUx6S0xzZEE5aEhvY0krVmJqTms0T3RxMzBSek1MeUN2K0c4V2VzK1dOSFZEcm1VOVpmTUU0STFCNzBKK0pSaEN4VDhZK28vK0lZVHlVdWFJeGNXZEtpSFNKWVFEaTlrRTkydGZhWVZtWWg5Rk9XUUpCTklyRFMwVXV0cFkvc2FtcS8wcDM3bHhwSkpGUXlycGlveVIwc1NEL0FqaXlHS3pCSHpRQWt2T0VHaE1obTBtUDJWazc2UEhZWmpHKzVMM2RQWVNQcXRGYnE5bDI4dStncWwvVjNXdzRVUmxBbnNHL0ZHcDhBVitLQ05uVWRtVEtjSzhBQ2xmTm1FdjRTTW5SL3hhdDdXaDVtUUc2a3NDUEVJZkxRV0d3MEFIT2ZQTkF3SVlSRFNsT1pzNDMrTTlWTW0xV3p3MzBWNFJFbjdsY1hqbWhNdXlKbnlXWW1za0VKMEFBdC9FRXRrdGNCMEZUeG13bk9VTE5SRGFjRmpDWE15ZHFZU2k2QUhPejhiUWZUcUxIQWdNQkFBR2pnZ1FKTUlJRUJUQWZCZ05WSFNNRUdEQVdnQlJSYVArUXJ3SUhkVHpNMldWa1lxSVN1Rmx5T3pBZEJnTlZIUTRFRmdRVUN0K3JFMmxyTHhZU0pUQ2ZWRkFUNEdlQ3JKSXdQd1lEVlIwUkJEZ3dOb0lPS2k1allXWmxkMlZzYkM1amIyMkNER05oWm1WM1pXeHNMbU52YllJV1pHVnBjeTF3Y205a0xtTmhabVYzWld4c0xtTnZiVEFPQmdOVkhROEJBZjhFQkFNQ0JhQXdIUVlEVlIwbEJCWXdGQVlJS3dZQkJRVUhBd0VHQ0NzR0FRVUZCd01DTUhVR0ExVWRId1J1TUd3d05LQXlvRENHTG1oMGRIQTZMeTlqY213ekxtUnBaMmxqWlhKMExtTnZiUzl6YUdFeUxXaGhMWE5sY25abGNpMW5OaTVqY213d05LQXlvRENHTG1oMGRIQTZMeTlqY213MExtUnBaMmxqWlhKMExtTnZiUzl6YUdFeUxXaGhMWE5sY25abGNpMW5OaTVqY213d1RBWURWUjBnQkVVd1F6QTNCZ2xnaGtnQmh2MXNBUUV3S2pBb0JnZ3JCZ0VGQlFjQ0FSWWNhSFIwY0hNNkx5OTNkM2N1WkdsbmFXTmxjblF1WTI5dEwwTlFVekFJQmdabmdRd0JBZ0l3Z1lNR0NDc0dBUVVGQndFQkJIY3dkVEFrQmdnckJnRUZCUWN3QVlZWWFIUjBjRG92TDI5amMzQXVaR2xuYVdObGNuUXVZMjl0TUUwR0NDc0dBUVVGQnpBQ2hrRm9kSFJ3T2k4dlkyRmpaWEowY3k1a2FXZHBZMlZ5ZEM1amIyMHZSR2xuYVVObGNuUlRTRUV5U0dsbmFFRnpjM1Z5WVc1alpWTmxjblpsY2tOQkxtTnlkREFNQmdOVkhSTUJBZjhFQWpBQU1JSUIrQVlLS3dZQkJBSFdlUUlFQWdTQ0FlZ0VnZ0hrQWVJQWR3QXBlYjd3bmprNUlmQldjNTlqcFhmbHZsZDluR0FLK1BsTlhTWmNKVjNIaEFBQUFYQ21HK2FjQUFBRUF3QklNRVlDSVFDSUtFTGFLc1lFMExJeXlZS2VrQTZteEd2OVFkZytOWHNGckp3Uk9iVUxaUUloQU5aRmh6R01Fb2pVdnZoOW0rYUkxRGZFb0QrZmxBZWJBNE96TXgvMXhobjhBSFlBSWtWRkIxbFZKRmFXUDZFdjhmZHRodUFqSm1PdHdFdC9YY2FEWEc3aUR3SUFBQUZ3cGh2bTl3QUFCQU1BUnpCRkFpQVljTFlaRGR6M0xNTC9URHNKYnNQeUgxRlNVbE5WdlhJOGpVVkdldDVxR3dJaEFJV1NsYlJIVXZKMEVNank5UlMyQkFsWVI4VWxqWkJIcGRtd3ZyV1MvbkFWQUhjQXBMa0prTFFZV0JTSHV4T2l6R2R3Q2p3MW1BVDVHOSs0NDNmTkRzZ04zQkFBQUFGd3Bodm1uZ0FBQkFNQVNEQkdBaUVBeVFKdDhLRmtKSmU4R3JXc0ZRV2pqTXo1aFpPMkMzdjJpQkU3VjRWTW5Pb0NJUUNidmpIM2huOGNkdnJyNklzbE5XTmhpQ3lLekdjL1NtdmY5cnJNMndIbFNnQjJBRUhJeXJIZklrWktFTWFoT2dsQ2gxNU9NWXNiQSt2clM4ZG84SkJpbGdiMkFBQUJjS1liNXBzQUFBUURBRWN3UlFJaEFNZmF3T2lhQjRjYk5FRmNlUE5pRW00VzBpdmh4ZXZTS1AweHBzOWpLZ0UzQWlCNWtLbFA1MXd0VmJEVWxnaGxKNVpHemFsYlJ3cXlSclpWSEFmaTMvOFVLVEFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBWEMyUmhUMm52NVVEQ3ZYclhNMjU1Rk5iNkoxYjNGNDZlMW14bkhDNFNMcTZvLzVhZVhhMmpvS0pqK0ZzSlNaZ2dJQkJFNy9aalVqZ3MxbnFxS056SlM5cVFiaEQ3ZnArWER6MFdrcUM3Q3ZlTmQ5Q2p3cHhSYUNsRUc2U3Z6eU1xaUtoMWVEWXpyNmUremVhVkFJUHlwejh0WnBjQTJKd1A3dUthcDkzMHpYc0VkaUZqV0hEL0U4dlVBQS9aYnYrNHk3Y09BUnBSTk5NTk5laE9FMGVpMVBhb1JYUU9yYVBQVThaVy96SlpCRWl0OVJlZncwU3RTMTRZcFM3UWRHM25obGdwQzhlS1hWOXcxT3IyaVNVZC9kK0hxWW5BVWZDWENpeEhMSTBidUF2d3p5V0Y2djZ4aXlqV2xwdmlKSjB2YitzYk5xempvWnFudUFwcDhlSjhBPT08L2RzOlg1MDlDZXJ0aWZpY2F0ZT48L2RzOlg1MDlEYXRhPjwvS2V5SW5mbz48L2RzOlNpZ25hdHVyZT48c2FtbDpTdWJqZWN0PjxzYW1sOk5hbWVJRCBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjEuMTpuYW1laWQtZm9ybWF0OnVuc3BlY2lmaWVkIj4wZjAyMjZhMy1hYmM3LTRjNjItOTQyYi1mMTA3YzA0Zjc5MmQ8L3NhbWw6TmFtZUlEPjxzYW1sOlN1YmplY3RDb25maXJtYXRpb24gTWV0aG9kPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y206YmVhcmVyIj48c2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uRGF0YSBOb3RPbk9yQWZ0ZXI9IjIwMjAtMTAtMjNUMDA6MDI6NDBaIiBSZWNpcGllbnQ9Imh0dHBzOi8vd2VsbHRvay5xdWl0bG9naXgub3JnL1NTTy9Db25zdW1lLmFzcHgiPjwvc2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uRGF0YT48L3NhbWw6U3ViamVjdENvbmZpcm1hdGlvbj48L3NhbWw6U3ViamVjdD48c2FtbDpDb25kaXRpb25zIE5vdEJlZm9yZT0iMjAyMC0xMC0yMlQyMzo1OTozNVoiIE5vdE9uT3JBZnRlcj0iMjAyMC0xMC0yM1QwMDo1OTo0MFoiPjxzYW1sOkF1ZGllbmNlUmVzdHJpY3Rpb24+PHNhbWw6QXVkaWVuY2U+PC9zYW1sOkF1ZGllbmNlPjwvc2FtbDpBdWRpZW5jZVJlc3RyaWN0aW9uPjwvc2FtbDpDb25kaXRpb25zPjxzYW1sOkF0dHJpYnV0ZVN0YXRlbWVudD48c2FtbDpBdHRyaWJ1dGUgTmFtZT0iVVVJRCI+PHNhbWw6QXR0cmlidXRlVmFsdWU+MGYwMjI2YTMtYWJjNy00YzYyLTk0MmItZjEwN2MwNGY3OTJkPC9zYW1sOkF0dHJpYnV0ZVZhbHVlPjwvc2FtbDpBdHRyaWJ1dGU+PHNhbWw6QXR0cmlidXRlIE5hbWU9IlJlbGF5U3RhdGUiPjxzYW1sOkF0dHJpYnV0ZVZhbHVlPi9xdWl0L2dvYWxzLmFzcHg8L3NhbWw6QXR0cmlidXRlVmFsdWU+PC9zYW1sOkF0dHJpYnV0ZT48c2FtbDpBdHRyaWJ1dGUgTmFtZT0idXNlcm5hbWUiPjxzYW1sOkF0dHJpYnV0ZVZhbHVlPjEwMDAwNTJfZTwvc2FtbDpBdHRyaWJ1dGVWYWx1ZT48L3NhbWw6QXR0cmlidXRlPjxzYW1sOkF0dHJpYnV0ZSBOYW1lPSJ0YXNrIj48c2FtbDpBdHRyaWJ1dGVWYWx1ZT4zMzcxNmI1Mi0zNzIyLTQxZDctOGExZS1kNzliZDliMWQ1YzY8L3NhbWw6QXR0cmlidXRlVmFsdWU+PC9zYW1sOkF0dHJpYnV0ZT48L3NhbWw6QXR0cmlidXRlU3RhdGVtZW50PjxzYW1sOkF1dGhuU3RhdGVtZW50IEF1dGhuSW5zdGFudD0iMjAyMC0xMC0yMlQyMzo1OTo0MFoiIFNlc3Npb25JbmRleD0iXzViOTNhZTQ3ZDNiYzJhYjRkNDY5YjEzNWViODE0ZjUxIj48c2FtbDpBdXRobkNvbnRleHQ+PHNhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY+dXJuOmZlZGVyYXRpb246YXV0aGVudGljYXRpb246d2luZG93czwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj48L3NhbWw6QXV0aG5Db250ZXh0Pjwvc2FtbDpBdXRoblN0YXRlbWVudD48L3NhbWw6QXNzZXJ0aW9uPjwvc2FtbHA6UmVzcG9uc2U+
What browser are you using to test? IE11 has URL length limitations that are shorter than what IIS can handle.
In the tests in the link above, IE11 was able to handle up to "4043" characters in the URL.
It also appears there are 2 places where your update might need to be made.
<configuration>
...
<system.webServer>
...
<security>
<requestFiltering>
<requestLimits maxQueryString="8192" />
</requestFiltering>
</security>
</system.webServer>
</configuration>
and
<configuration>
...
<system.web>
...
<httpRuntime ... maxQueryStringLength="8192" />
</system.web>
</configuration>
In situations where a large amount of data needs sent to an application, like in a SAML request, the request is made as a POST with the data in the request body, rather than as a GET, so they are not subject to URL length limitations.
I also don't think this issue is a Kentico problem, unless you are seeing different results in a new WebForms application project with the same web.config settings.
I could not find the specific answer to this when searching so I'm posting my solution here.
We were working fine with SignalR for a long time, then some users started getting 404 errors on the start and connect calls from AngularJs/jQuery to the server. Negotiate would work fine though and return a 200 code.
It turns out by default the server side (ASP.NET 4.6.1) must impose a limit on the size of a URL and instead of returning a 414 (Request-URI Too Long) like you might expect it must just truncate the URL at a length around 2,083 and still try to process it. I'm assuming the 404 is the SignalR hub responding because now the truncated string has query string parameters that don't match what is expected. We were seeing it because we were passing a couple custom values and the security access token via query string parameters which increased the size. The access token was passed via query string because we wanted to use websockets and headers don't exist for websockets. As you add more attributes and roles to your token it will grow which is what put us over the default size limit.
The fix is easy. Just update your server web.config to allow longer URLs.
<system.web>
<httpRuntime targetFramework="4.5" maxRequestLength="30000000" maxUrlLength="40960" maxQueryStringLength="2097151" />
</system.web>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="30000000" maxUrl="40960" maxQueryString="2097151" />
</requestFiltering>
</security>
</system.webServer>
We have a web service which is denys access to all except a single IP address. This is configured like so
<location path="ASMX/Service.asmx">
<system.webServer>
<security>
<ipSecurity allowUnlisted="false">
<clear />
<add ipAddress="[Our IP address]" allowed="true" />
</ipSecurity>
</security>
</system.webServer>
We recently installed a Web Application Firewall, so now all traffic now comes from a single source. The firewall however collects the origin IP and puts it into a request header called 'X-Origin-IP'.
Is it possible to use the web.config to read this new header and only allow where certain value exists, or is it better to drop into the code and perform the analysis there?
Context
Umbraco CMS website runs on Azure as App Service
Scheduled Publishing
One of the Umbraco functionalities is to allow to publish content on a given time. The publish functionality makes a HTTP call to same web site (or a different server but same website in load balanced environment).
API call url:
http://sample-site-umbraco.azurewebsites.net/umbraco/RestServices/ScheduledPublish/Index
IP Security
Due to client requirements, access to the site is restricted to a given list of IP addresses. This task is being completed with IP Security restriction in web.config.
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="52428800" />
</requestFiltering>
<ipSecurity allowUnlisted="false" denyAction="NotFound">
<!-- "clear" removes all upstream restrictions -->
<clear />
<!-- permit the loopback address -->
<add ipAddress="127.0.0.1" allowed="true" />
...
...
...
<!-- domain Name for Scheduled Publishing -->
<add allowed="true" domainName="sample-site-umbraco.azurewebsites.net"/>
</ipSecurity>
</security>
Problem
When IP Security is turned on, the HTTP call to publish API is being blocked as not white listed one.
API call response Status Code and Content:
404 - NotFound
"The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."
Problem Thread on our.umbraco.com
Fix attempts
Adding domainName to the list of allowed entries
<!-- domain Name for Scheduled Publishing -->
<add allowed="true" domainName="sample-site-umbraco.azurewebsites.net"/>
This solution doesn't work. Calls are still being blocked.
Question
How this can be fixed? Is there any functionality that can be override?
Ok, I've found the solution. I think it will work.
I've found this question on stackoverflow and it worked :)
Solution
Solution is to add ALL outbound IP addresses into System.WebServer > Security > ipSecurity > [List].
Outbound Ip Addresses are comma separated list of ips.
You need to add all of them to the WhiteList in web.config.
Drawback
I'm not sure if the list of Outbound Ips is static and will not change in the future...
The following results in successful sub-second page loads.
<add name="test"
connectionString="Data Source=TEST_ORACLE;User Id=user;Password=password;" />
The following subtle change to use the app pool's custom identity results in successful page loads that are 20+ times slower.
<add name="test"
connectionString="Data Source=TEST_ORACLE;User Id=/;" />
It appears that I at least got the trusted connection to work. What am I missing?
Try Integrated Security=SSPI; instead of User Id=/;
Does your app pool identity have network logon rights?
The connections strings that I use look like
<add
name="myOracleConnection"
connectionString="Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=MyServer)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=XE))); User Id=MyUser; Password=MyPassword;"
providerName="system.data.oracleclient"/>
I.e. I do not rely on these external configuration files (were they named .ora? I forgot it).
Maybe you can lower dependencies and side-effects if you also try to make your connection string self-containing with everything included?